using #FILL_ROM to add safety backup on PIC24

[Oli]

Hi All

I'm looking to fill all the unused space on the processor with an instruction that will 'recover' the program if it goes into the weeds. I guess I have 2 options

1/ use a reset instruction, which will reset the whole processor (I think this is the best option)

2/ use a GOTO instruction to point it to the beginning of the program.

Are there any best practices in doing this? Could somebody also point me in the direction of how to implement this i.e. calculating the hex values.

Many thanks

[Jerson]

Have you considered using the watch dog timer in your pic? It's meant for things like this.
_________________
Regards
Jerson Fernandes

[bkamen]

Watchdog is the way to go.

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[Oli]

I'm already using it, but I asked because this is actually specified in the PIC24F WDT timer reference

[bkamen]

Ahhh..

Well, if you're going to fill ROM with a value, fill it with the opcode to jump/goto/branch to the reset location OR (maybe better) to a loop in memory that lacks the WDT reset. (I forget what it is.)

IIRC, when you erase the device, the default opcode is NOP. (I think)

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[FvM]

I don't think, that it's necessary to fill the ROM under normal condition. I also don't like it, because it would increase the size of firmware image files. WDT operation should be sufficient in most cases. In addition, you can "guard" critical functions or code parts, e.g. the code triggering the watchdog or writing to flash/EEPROM by preceeding while (1); or reset_cpu(); calls.

[bkamen]

I've never had to fill either.

I do find the recommendation he found interesting though.

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[SET]

I think the recommendation is for a scenario where 'out of control' code might actually execute the watchdog kick, and therefore will never recover. If 'Goto here' instructions were executed then it's guaranteed that the timer would expire and do a reset.

[balmer]

In the event that code runaway occurs, the MCU could continue accessing memory until it reaches
an illegal address where, finally, a system reset will occur.
In the meantime, many undesired events could happen as a result of the code running where it should not.
To protect from the potentially harmful effects of code runaway, it is generally good practice to fill unused memory
with known values such as software RESET op-codes, SWI, or NOPs.

[Ttelmah]

Key is that the manufacturers of the chip have taken care of this for you.

The important things for the 'fill' instruction are:
1) It must not reset the watchdog.
2) It must not affect any I/O.

Obvious candidate is 'NOP'.
Microchip, on all their chips have made the reset memory value '0xFF', a NOP.
This is deliberate, and avoids the need to write anything into erased memory.

Best Wishes

[bkamen]

The problem with the NOP is that if it's encountered somewhere in between code, the cpu can slide into another section of code.

So the default NOP is not really an answer for the truly paranoid.

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[Ttelmah]

This then simply 'behoves you' to always put a dummy leader in front of such code sections. The only one that is likely, is a bootloader at the top of memory, and I do exactly this.
There was a 'rule' years agao, that any code containing a watchdog reset, or calling a watchdog reset, should have a single instruction in front of it, that either jumps back to address zero, or jumps round it, to prevent 'walkthrough'. This is still good advice.
Filling the ROM, though it sounds nice, increases programming time so much, on some chips, that it really has to be avoided.

Best Wishes

[Oli]

I think I will leave it as it is. Thanks for your replies and advice

Oli