Skip to main content
Topic: PATCH: flash size fixes(?) pic24 (Read 8887 times) previous topic - next topic

PATCH: flash size fixes(?) pic24

The pic24 sizes were/are off. The page size isn't used currently for page erase, but the flash size may have been causing problems.

EDIT forgot the file

Re: PATCH: flash size fixes(?) pic24

Reply #1
Could you please make the sizes more "undersandable" 44024 is hard to read probably make it "0xabff - 8" to make it more readable ?
Also ... this patch will break stuff, so i will not apply it :-) ...
Code: [Select]
+                               .size = size = 175096 //0x2abf7-0x0

We should keep the repo as clean as possible, and without personal junk like:
Code: [Select]
+               //.row_size = 128, // 64*word
Could you also change the "EEPROM" to "FUSE" ? it seems that I did some error, and it got copied multiple times.

Other than that... I have no means right now to test it. I will look at it later.

Re: PATCH: flash size fixes(?) pic24

Reply #2
I noticed the errors(some) and mentioned them on IRC shortly after, it is from rapidly backporting stuff from my local  The purpose being more "let someone know there is an issue" less "This patch needs accepted", due to the publicity of the adapter availablity. Someone had already put the correct value in the pirate, so it was just an oversight, and likely on a TODO somewhere.

You are under no obligation to apply my patches. I won't feel offended, promise. If I get something I feel important I'll format however you like, indent does wonders =)

I find the decimal much easier to read than the hex. And think extra math should be avoided, doing it once and inputing it in source leads to less wasted cycles. Yes an optimiser might fix it, however if you enter a solved number it doesn't have to.  Of course being me I reserve the right to change my mind repeatedly, sometimes in the same sentence!

--Short version description of the patch for manual application
The flash sizes are wrong  for the two PIC24, change the 64's size to 44024 (~22k*word), and change the 256's size to 175096(87k*word).
The page size can be ignored, it's only used for some allocation there is no smart erase implemented, but it is 1024(512*word) for both.
The rest is crufty bits and errors...

You can verify these on datasheet page 9
picfj64ga002
http://ww1.microchip.com/downloads/en/D ... 39768d.pdf
picfj256gb106
http://ww1.microchip.com/downloads/en/D ... 39907b.pdf

I Obviously did not test that patch either.
Test procedure requires
  three hex files. 1 each smaller larger and boundary sized.
  bus pirate, and one afflicted chip-type.

Writing the larger file un-patched will fail verification, the device function however erratically missing upper memory.
With the appropriate size applied to the source. The verification read back and HEX parser should catch any anomaly.
Verify visual in MPLAB, or other. Boundary sized does not overwrite config/id/reserved spaces. Smaller sized leaves correct buffered length.

Re: PATCH: flash size fixes(?) pic24

Reply #3
Just for example, my current data is in this form.
Code: [Select]
,{
        .family = FAMILY_18xxxx
        ,.name          = "PIC18F2550"
        ,.ID            = 0x00001240
        ,.ID_ADDR      = 0x003FFFFE
        ,.ID_MASK      = 0x0000FFE0
        ,.word_size    = 0x00000002    //2
        ,.page_size    = 0x00000040    //64
        ,.row_size      = 0x00000020    //32
        ,.memmap = {
                [PIC_MEM_FLASH] = {
                        .base = 0x00000000
                        ,.size = 32768  //0x7fff-0x0
                }
                ,[PIC_MEM_FUSE] = {
                        .base = 0x00300000
                        ,.size = 14    //0x30000d-0x300000
                }
                ,[PIC_MEM_EEPROM] = {
                        .base = 0x00000000
                        ,.size = 256    //0xff-0x0
                }
        } //END mem map
} // END device: PIC18F2550
,{
        .family = FAMILY_24xxxx
        ,.name          = "PIC24FJ64GA002"
        ,.ID            = 0x04470000
        ,.ID_ADDR      = 0x00FF0000
        ,.ID_MASK      = 0xFFFF0000
        ,.word_size    = 0x00000002    //2
        ,.page_size    = 0x00000200    //512
        ,.row_size      = 0x00000040    //64
        ,.memmap = {
                [PIC_MEM_FLASH] = {
                        .base = 0x00000000
                        ,.size = 44028  //0xabfb-0x0
                }
                ,[PIC_MEM_FUSE] = {
                        .base = 0x0000ABFC
                        ,.size = 4      //0xabff-0xabfc
                }
        } //END mem map
} // END device: PIC24FJ64GA002
,{
        .family = FAMILY_32xxxx
        ,.name          = "PIC32MX120F032B"
        ,.ID            = 0x04A06053
        ,.ID_ADDR      = 0xFFFFFFFF
        ,.ID_MASK      = 0x0FFFFFFF
        ,.word_size    = 0x00000000    //0
        ,.page_size    = 0x00000000    //0
        ,.row_size      = 0x00000000    //0
        ,.memmap = {
                [PIC_MEM_FLASH] = {
                        .base = 0x1D000000
                        ,.size = 32768  //0x1d007fff-0x1d000000
                }
                ,[PIC_MEM_FUSE] = {
                        .base = 0x1FC00BF0
                        ,.size = 16    //0x1fc00bff-0x1fc00bf0
                }
                ,[PIC_MEM_BOOT] = {
                        .base = 0x1FC00000
                        ,.size = 3056  //0x1fc00bef-0x1fc00000
                }
                ,[PIC_MEM_RAM] = {
                        .base = 0x00000000
                        ,.size = 8192  //0x1fff-0x0
                }
        } //END mem map
} // END device: PIC32MX120F032B

 The full device list for only the existing four implemented specifications totals already around 100 devices. Adding the pic32mx adds 69, PIC18F97J60 specification is 9, and the ds33/pic24_GP another large block I think around 100-120

Re: PATCH: flash size fixes(?) pic24

Reply #4
Thanks AndThen, with the adapters on the way I really appreciate these contributions. It's really helpful to know where to look when the bug reports start flying in ;)
Got a question? Please ask in the forum for the fastest answers.

Re: PATCH: flash size fixes(?) pic24

Reply #5
Quote
Could you also change the "EEPROM" to "FUSE" ? it seems that I did some error, and it got copied multiple times.

You did it intentionally for special handling of the config when it is contained in the other section. Due to fixed page size, there are anomaly in the output HEX, if you read only the config area it outputs the rest of the area as blank memory.  I'm using a check  against the last read address and the fuse base, currently to test if it has been read already.

EEPROM to FUSE change requires a test in the PIC_ReadMemory. And the FLASH area size needs to include the FUSE area in those cases where it overlaps, do not subtract it.

---
issue: BP_PIC424Read(), When called from the PIC_ReadMemory/PIC24_Read it is asked to read a byte count, but returns six times as much data as requested.
---
issue: PIC24_Read(), When called from the PIC24_ReadID it is asked to read as iteration, it should be a byte count. 8 bytes, or 2 words, not 1 "block"
---
issue: BP_PIC424Read(), Does not properly unpack data. Output has no padding inserted. Output should be MSB and LSW
---
issue: PIC24_ReadID(), Ug and uh uhm, ya. All of the above.
---
issue: PIC24_Read(), addr when called from the PIC_ReadMemory() needs to be converted to a word address, divided by 2.
---
issue: PIC24 page_size, The current implementation of PIC24_Write requires this to be 256 bytes(0x100) or 64 32bit words, this is in fact the write/row size, the actual erase/page size is 2kb.
---
issue:  Flash sizes, for the 24FJ64GA002 (Bus pirate 3.5) size = 86*1024

***
pic24:
I've completed a write read test of the bpv3-BL44FW510-DUMP.hex, the read back is almost exact it only differs on the configuration words. The input has them as two single records(08), the output has them in a single block(10).

pic18:
I should do the full pic18 HV read write tests again maybe.
LV the stamp interface is too slow to toggle the lines and there is no room for another firmware command.

My hack attempt to write only the bootloader doesn't appear to have worked this time. I want to blame the new hardware since it has different parasites and no crystal capacitors.


pic32:
pic32 is still a four wire implementation.
TMS needs reconciled to a buspirate line. VPPHigh and VPPLow can probably be used, but I added/have an LVP line (intended for controlling the PGM line on pic18) assigned to TMS currently.

I forget the exact state of the read/write tests, I "think" they are/were pass. I was distracted by the pickit2..
Pickit2 PC-App source can be adjusted to load the PE, but again I forget the exact status, (from memory) erase works, read works, word write probably does not work, and block programming definitely does not.

***
I can provide only sloppy patches currently, since I was doing clean up and verification when the pic24 stuff appeared it is ugly again.  Oh and also the long device list will need recreation without the subtractions, and my Changelog is out of date.

Re: PATCH: flash size fixes(?) pic24

Reply #6
Could you provide any patch ?

I would like to fix the PIC24xxx readout, and PIC32 support. I can work even with sloppy patches, as long as the "procotol" is working :-).

Re: PATCH: flash size fixes(?) pic24

Reply #7
Dont worry about the patches . I think i got everything figured out.

Re: PATCH: flash size fixes(?) pic24

Reply #8
Sorry I didn't see this, I wasn't online yesterday I got to (yay) spent the day 'working on my sun burn/outside'.

Re: PATCH: flash size fixes(?) pic24

Reply #9
Just a quick FYI follow-up. The PIC18 Issues I mention were indeed hardware, it's USB regulator is malfunctioning. I haven't decided if I want to cut the chip off and replace it or add an external regulator