[PIC24HJ256GP210] Device ID becomes corrupted

[Ttelmah]

A row is 192 bytes. 64*3 byte words. Not 64*2.

Each instruction, is 3 bytes out of a 4 byte 'space'. The row is 64 of these
'spaces'.

The problem in the erratum, happens when data is written, not on the
erase.

[canadidan]

Good news - I think I solved it.

rom_write.c

I discovered the rom_write library in Compiler V5.044 - it wasn't in V4.106.

This library includes the rom_modify() function. This function handles page buffering, which was something I unsuccessfully tried to implement myself.

It still uses write_program_memory() in its rom_flush() function, but it does it by page - doubtful that it uses word programming method.

Results

I ran it overnight, and completed 1000 cycles without error.

To validate that the data was properly written, I have a few points:

* I still run the erase routine first. Thus, if rom_modify() didn't write the correct data, my application would have little chance of working.

* I did a ROM dump before and after a firmware upgrade, then compared the data. The updated data was properly recorded in the "after" dump. Verified this with 3 FW versions.

Drawback

Since it buffers the flash writes, my existing verification code doesn't work since it expects the HEX line to already be written. However, adding a verification stage to rom_flush() would be easy enough.

Going Forward

I will do more testing, and likely have to re-qualify a lot of the system. However, rom_modify() appears to be a better function to use than write_program_memory() for large data writing operations.

Helpful note to others: Since rom_modify() only flushes to ROM after a page boundary change, you will need to run rom_flush() at the end of your upgrade routine to ensure all data is written.

[temtronic]

OK... you got ANY hair left ??? Man this has been one nasty journey for you !!

[PCM programmer]

I admire that you didn't give up, you kept at it until the problem was solved.

[canadidan]

It's not quite resolved!

The firmware was originally programmed with V4.106.

I ported the BIOS to V5.044 fine, but the firmware had a bunch of bugs with the newer compiler.

The test last night was using V5.044 generated BIOS, and firmware HEX from V4.106.

I tested this morning using V4.106 generated BIOS and it failed.

-> I will now retest with V5.044 generated BIOS to confirm fix. If so, the solution is twofold:

1. Use rom_modify()
2. Use V5.044 compiler

** Stay tuned ***

@PCM programmer - I have no choice, this is my 8-5 job!

@temtronic - still some hair, but I'm only young yet

[Ttelmah]

Obviously be aware that you are going to hit the 'life' limit on your test
chip fairly soon....

The 'guaranteed' life is only 100 cycles. 1000 is the 'typical'.

[canadidan]

@Ttelmah - this is true, good point. However, wouldn't failure only occur in the blocks being erase/written? Even after 1000 cycles, the device ID block shouldn't become corrupted right?

Compiler V4.106 - 172 cycles before device ID corrupted
Compiler V5.044 - 1735 cycles before device ID corrupted

To confirm - I will start with two brand new PICs and test each version of the code.

[Ttelmah]

Yes. I was simply warning that the 'test' chip you have run 1000 cycles on,
was likely to soon start failing...

[canadidan]

Verdict

After a race to the death with two brand new ICs, my original hypothesis doesn't hold up:

Hypothesis: along with using rom_modify(), I need to port my code from V4.106 compiler to V5.044.

Experiment: two brand new PIC24HJ256GP210 ICs, one with FW compiled using V4, one compiled with V5. Continuous firmware upgrade cycles.

Results:

* Original code: ID corruption after average ~165 cycles (range: 1 to 600)
* rom_modify, V4 (new IC): ID corruption after ~800 cycles
* rom_modify, V5 (new IC): ID corruption after ~1700 cycles
* rom_modify, V4 (new IC #2): still going after 1900+

Conclusion:

* Results suggest compiler version didn't make a difference.
* Skipping the erase cycle, or page aligning it, also had no measurable impact on ID corruption.
* Using rom_modify() has had the only measurable impact.

To minimize overall design impact, I will stay with the "stable" V4.106 environment but bring the rom_write.c library into my project.

[Ttelmah]

The danger with this is that the internal code for write_program_memory
may well also have been changed in the V5 compiler, so rom_modify
may not work as well with 4.106.

[canadidan]

I agree, and I wish we had transparency into that particular function.

My primary goal was to reduce instances of the Device ID becoming corrupt upon the very first upgrade. Of the 5 units tested with the new code, none have corrupted upon the first try.

We are aiming for a new generation hardware design by end of year, and I'll be going for something ARM Cortex-based I think. Still have to maintain this old design!

[Ttelmah]

You could do a simple compare of the assembly generated. If it is the
same in V4, 'hurrah', if not then I'd say you really need to be compiling
with the V5 compiler.

[canadidan]

Great idea!

The initial setup is the same (no surprise):

[newguy]

You'll have to dig through the errata first, then the data sheet. Microchip might also have some app notes dealing with the issue. Do some reading and the assembly will start to make sense.

PS: want a job? Your attention to detail is to be commended.