removing illegal and critical bytes from your code

[gjunh]

I want to know how to view the critical bytes of a .list file. Which byte above the location is critical bytes, is the one to be removed

[AvaTar]

Not quite sure what you talk about, but I assume the map file.

This file is a human-readable list of the mapping between code/data (functions & variables) and actual memory addresses of the MCU device.

It is a byproduct of the linker, and only for reference. Editing it has no effect whatsoever on the firmware. If it shows errors and warnings, you need to modify the source code and/or the build process.

What are "illegal/critical bytes" in this context ?

[gjunh]

In the application note AN1015, section 2.5

A critical byte is an instruction switching MCU in low power modes which is decoded by the

microcontroller and forces it to stop executing any further instructions.

When the PC is corrupted it often becomes desynchronized (as most of the instructions

have several bytes), and as a result it may read and decode critical bytes.

To check and minimize the occurrence of these critical bytes you can check the program

".list" file.

Very often critical bytes are generated by the compiler as label address bytes. In this case, if

you simply insert one or several NOP instructions, all the label addresses will shift and this

will change the critical byte value to another value.

[AvaTar]

Some while ago when I last dealt with STM8, and the device never involved a low-power mode.

> When the PC is corrupted it often becomes desynchronized (as most of the instructions

have several bytes), and as a result it may read and decode critical bytes. To check and minimize the occurrence of these critical bytes you can check the program ".list" file.

I have never read such a strange "recommandation" before. Sounds somehow like a bug cover-up.

Still, the list file (map file) is output only. You would need to make modification in the sources. Every other change in the sources will potentially affect your "fixes", so this method seems the least preferential method to me.

But if the MCU goes astray and tries to execute data, there is something wrong. If you find such inadvertend sleep mode instruction pose a problem to your application, consider a watchdog. If your device has none, or it would suspend in the sleep mode as well (which would be rather strange...), use an external watchdog. The subsequent reset should put the MCU back on track.

Keep in mind that watchdog are a tool to deal transient problems (like EMI), not to cover up software bugs in your code.