[PIC24HJ256GP210] Device ID becomes corrupted

[canadidan]

@dexta64

The ground pins are all connected with a ground-plane:



Yes, it is a switched regulator. Do you believe a lower ESR cap than the sub-1Ω Samsung is required?

I don't understand your meaning RE: hard disk PCB design.

The programming routine looks like this, and takes a standard CCS-generated HEX file as input:

[dexta64]

PIC24HJXXXGPX06 / X08 / X10 Family Silicon Errata and Data Sheet Clarification. Page 15.

"32. Module: Device ID Register On a few devices, the content of the Device ID register can change from the factory programmed default value immediately after RTSP or ICSP™ Flash programming.
As a result, development tools will not recognize these devices and will generate an error message indicating that the device ID and the device part
number do not match. Additionally, some peripherals will be reconfigured and will not function as described in the device data sheet"

Have you considered this place?

I don't understand what your program code is doing, but I think you're trying to program the processor.
There is a situation where you have deleted an address that will not be deleted from the processor. I think the processor had an id number and other internal connection settings. "Silicon Errata" says it.
0xFF0000-0xFFFFFE Are you trying to write something in this program range? see datasheet on page 27. Here says the device ID.

You need to make sure that you have correctly emptied the program area of ​​the processor. The processor will work inconsistently even though there is one bit stuck in the previous program.

Have you changed the compiler version? It cannot be guaranteed that the compiler does the right job.

[Ttelmah]

Ouch.

Immediate comment. If it is in the errata, then there will be a fix or
work-around in this.

Checking, interesting it says 'on a few devices'. So not universal.

However it does give an alternative programming sequence.
Pretty horrible. You must use row programming, not word programming,
and reload all data latches ending in a specific bit pattern. Yetch.
Can be written fairly easily. You might want to talk to CCS and see if they
can add this to the internal programming code on this chip.

[canadidan]

@dexta64

Errata

Yes, I did consider that. That's why I asked you, "Is it correct to say that this would be row programming, not word programming?"

What is the code doing

The code is writing to the internal flash (programming the processor, RTSP). My program only exists in this range:

[Ttelmah]

The point is that even if the compiler is using row programming (would
have to look at the code to see), there has to be this 'reload' of
particular data latches. Unless CCS has implemented this as a fix
for this chip, this won't be being done. The compiler age makes
it very likely that a fix for this won't be there. Your compiler predates
that particular part of the erratum being published....
CCS are pretty good at implementing errata, though this one is so
horrible that it is more complex to fix than most.

You have not actually shown us in your posted bits of code, what
'DATA_LENGTH' is set as?. If this is a row, and the write starts at the
row boundary, then the compiler should generate a row write.
Understand also that if this is the case, the compiler _will_ be erasing the
row before writing. If you are separately erasing (as you seem to show),
this will be wasting chip lives.

I realise you do show 'DATA_LENGTH', as a single line of the Intel hex file.
This is not a row. On this chip the flash row is 192 bytes. You would
have to buffer this much data and write this much at a time to switch
to row operation.

[dexta64]

I did a little experiment with your flash erase procedure.
You just seem to be wiping off some of the flash. the procedure begins to delete from 0x800.
first started typing address 0x803 = ff, 0x807 = ff, 0x80b = ff, 0x80f = ff, 0x813 = ff, 0x817 = ff ...

0x800,0x801 and 0x802 nothing is done to these addresses. The procedure does this in i=153. i=153 will exit the procedure.

[canadidan]

Understood, both of you I didn't write this code, just inherited it, and your help dissecting it is huge.

Data Length Packing

ROW = 192 bytes = 64 instructions
PAGE = 1536 bytes = 512 instructions = 8 ROWS

FLASH_ERASE_SIZE = 1536 bytes = 1 PAGE

Wasteful / Incorrect Erase Routine

@dexta64, you are right - this code doesn't behave as desired.

[Ttelmah]

The commonest cause of faults, is pointers.
In late V5 compilers CCS implement explicit pointer checking.
So in your program memory write for example, you would probably
have to cast the pointer to be to int8 *. On the older compilers mixed
types were accepted without complaint.

[dexta64]

Look at Datasheet's page 62, telling you what to do. http://ww1.microchip.com/downloads/en/devicedoc/70175h.pdf

Sometimes a datasheet may not have enough information. In another datasheet, the process can be explained in more detail. For example, compare your PIC24FJ256GA110 with the datasheet of this processor.

Sometimes it may not help you in a forum just about the pic. Follow the forums of other processors. As a result everyone is dealing with the same problems.

[dexta64]

[Ttelmah]

You are missing the + to increment address_erase....

[canadidan]

@dexta64 - actually I don't want it to touch the bootloader - this should be protected (recovery mode).

I'm still reworking this code - basically I want to buffer a whole page then write in one shot. I have enough RAM to do this. The trick is that HEX files aren't always in address sequence...

@Ttelmah - you mean this doesn't work?

[Ttelmah]

dexta64 originally posted his version without the + ....

[canadidan]

Update

Erase loop does not seem to be the problem

* Commented out the erase loop: Corruption still occurs

* Page-aligned the erase: Corruption still occurs

[dluu13]

Glad to know I'm not the only guy who breaks everything around here :P