4 ms·

Watchdogs are one of the more frustrating types of issues to debug. Chris's overview of how to implement them properly, and investigate resets is an amazing res

by fra 7y ago

Watchdogs are one of the more frustrating types of issues to debug. Chris's overview of how to implement them properly, and investigate resets is an amazing resource I wish I had earlier in my career.

RealityVoid 7y ago
Heh, I work in embedded and, IMO, they were one of the most fun issues to debug in the begging of my career. Mostly, if I had such an issue, I enabled the ISR triggering and just before the context got trashed, I looked where the program was. Things got pretty obvious then. Once you get the hang of it, it becomes pretty straightforward. And it's great training on how the HW looks like and functions! Granted, on more lower powered systems, with fewer, more primitive debugging options (looking at you, PIC) things miiight look a bit more painful. Thankfully, such systems are (much) smaller. IMO, the _most_ painful issues to debug are memory corruption issues happening on large systems without MPU enabled.
- fra 7y ago
  You’re right, if it reproduces at your desk you’ve got some good tools at your disposal. Collecting enough state to fix them from a customer report is tricky, I would say.
- raxxorrax 7y ago
  On the other side even the smallest PICs and Atmels have sooo much EEPROM and flash memory available. I am still amazed how much better these chips got in the last decade. You have all the I/O you could want, nearly endless memory and the chip costs less than a bubblegum. In smaller systems for memory checks I always have a complete self-check routine at boot. Although I cannot even remember when I had the last error for internal memory. The quality seems to be quite high, even after many read/write cycles. Never implemented that for a system with virtual memory. What I mostly miss in embedded systems isn't debugging, it is having real unit tests without having the target board and all the periphery installed in a laboratory, which is the only location I can feasibly run any tests. And those are mostly restricted to integration tests.

by fra 7y ago

RealityVoid 7y ago

Heh, I work in embedded and, IMO, they were one of the most fun issues to debug in the begging of my career. Mostly, if I had such an issue, I enabled the ISR triggering and just before the context got trashed, I looked where the program was. Things got pretty obvious then. Once you get the hang of it, it becomes pretty straightforward. And it's great training on how the HW looks like and functions! Granted, on more lower powered systems, with fewer, more primitive debugging options (looking at you, PIC) things miiight look a bit more painful. Thankfully, such systems are (much) smaller. IMO, the _most_ painful issues to debug are memory corruption issues happening on large systems without MPU enabled.

fra 7y ago
You’re right, if it reproduces at your desk you’ve got some good tools at your disposal. Collecting enough state to fix them from a customer report is tricky, I would say.
raxxorrax 7y ago
On the other side even the smallest PICs and Atmels have sooo much EEPROM and flash memory available. I am still amazed how much better these chips got in the last decade. You have all the I/O you could want, nearly endless memory and the chip costs less than a bubblegum. In smaller systems for memory checks I always have a complete self-check routine at boot. Although I cannot even remember when I had the last error for internal memory. The quality seems to be quite high, even after many read/write cycles. Never implemented that for a system with virtual memory. What I mostly miss in embedded systems isn't debugging, it is having real unit tests without having the target board and all the periphery installed in a laboratory, which is the only location I can feasibly run any tests. And those are mostly restricted to integration tests.