This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Error Code Logging for Devices in the Field

I am currently trying to come up with a viable strategy to log error codes that arise while my device is being used in the field. When an unexpected error code arises, I would like to be able to save that on the device so that when it is paired with a central, is has the ability to offload any error codes that it has thrown so that the central can then upload those to our servers, allowing us to debug errors that are occurring on devices in the field. Has anyone come up with a robust strategy for doing this?

I have a few possible strategies that I have outlined below:

  • My board has an external memory chip on it that is controlled over I2C. One strategy would be to allocate a section of that memory, and when and error code is thrown, write the code to this memory. The issue I see here is that if the error being thrown is a result of some I2C or external memory operation, then attempting to write the error code to external memory could cause another error to be thrown, which seems like it would result in an infinite loop of error throwing.

  • Log the error codes to PStorage. I see the same errors here, as well as having to deal with the callback function while in the app error check function.

  • Save the value in some retained registers and then check those registers upon booting up, and then put them somewhere more permanent. Again, the problem here is that if saving the code is whats causing an error to be thrown, this could result in a loop.

I'm not sure if I'm overthinking the scenarios in which problems occur with these solutions, or I'm overlooking a more obvious solution to this problem, but if anyone has implemented something with a similar intent, I'd be interested in hearing what strategy you used.

Thanks,

Seth

Parents
  • Hi Seth,

    Regarding your solutions, my opinion is:

    1. It's true that if the error is from I2C then it would be a infinite loop to try to write to the external memory. But you can add a counter to stop that if it exceed a number of error report.

    2. You can try to write to flash. But using pstorage might be not a good idea because the issue may come from the stack and there is a chance that the stack stopped working. If you plan to reset the chip/the connection after the issue occurs, you can disable the stack and access the flash directly it would reduce the risk of getting into another error.

    3. It would be a good idea to do so, and reset the chip to store the error code to flash/I2C ram or report the issue to the master. However there is a limit of the size of the retention register, only 8bit can be used. But you can index a list of errors and can assign a number for each of them, maximum 256 different error. Be aware that we use retention register to enter bootloader mode.

Reply
  • Hi Seth,

    Regarding your solutions, my opinion is:

    1. It's true that if the error is from I2C then it would be a infinite loop to try to write to the external memory. But you can add a counter to stop that if it exceed a number of error report.

    2. You can try to write to flash. But using pstorage might be not a good idea because the issue may come from the stack and there is a chance that the stack stopped working. If you plan to reset the chip/the connection after the issue occurs, you can disable the stack and access the flash directly it would reduce the risk of getting into another error.

    3. It would be a good idea to do so, and reset the chip to store the error code to flash/I2C ram or report the issue to the master. However there is a limit of the size of the retention register, only 8bit can be used. But you can index a list of errors and can assign a number for each of them, maximum 256 different error. Be aware that we use retention register to enter bootloader mode.

Children
No Data
Related