| Electronics > Repair |
| Agilent 34461A corrupted flash |
| << < (16/41) > >> |
| ElectronMan:
--- Quote from: analogRF on July 30, 2023, 07:49:39 pm --- --- Quote from: ElectronMan on July 30, 2023, 07:44:01 pm --- It does support falling back to a backup config, but I don't see any other copies. That is probably optional (which would be why yours isn't attempting to load it). What does the spare area after that first page of the config look like? --- End quote --- all 00 all the way up to 0xC4000 --- End quote --- Are you certain you are reading the spare area? It is the extra 0x40 (64) bytes after the end of the 0x800 byte page. How were you reading the flash? There is definitely some calculation it is doing with the spare area in the code before it decides it is a bad block... I am just not sure what algorithm it is using. |
| analogRF:
--- Quote from: ElectronMan on July 30, 2023, 07:56:56 pm --- Are you certain you are reading the spare area? It is the extra 0x40 (64) bytes after the end of the 0x800 byte page. How were you reading the flash? There is definitely some calculation it is doing with the spare area in the code before it decides it is a bad block... I am just not sure what algorithm it is using. --- End quote --- I could be quite wrong about this. So here is what I did for this last dump: --- Code: ---p510> nand read 0x800000 0xc0000 0x4000 . . p510> md.b 0x800000 0x4000 --- End code --- so 0x4000 in the nand read might not mean the same as 0x4000 in the memory read? |
| analogRF:
for the previous dump I used 0x800 instead of 0x4000 in nand read but as you see the length of the file is 0x4000 and the first 4 bytes are crc32 and that leaves 0x3ffc of data as you suggested |
| analogRF:
ok for crc calculation I skip the first 4 bytes and select everything all the way up to 0x83F and do a crc32 i also tried selecting up to 0x7FF and also up to 0x3FFF and I never get those 4 bytes I am using HxD hex editor to do that |
| ElectronMan:
--- Quote from: analogRF on July 30, 2023, 08:03:51 pm ---for the previous dump I used 0x800 instead of 0x4000 in nand read but as you see the length of the file is 0x4000 and the first 4 bytes are crc32 and that leaves 0x3ffc of data as you suggested --- End quote --- --- Quote from: analogRF on July 30, 2023, 08:03:51 pm ---for the previous dump I used 0x800 instead of 0x4000 in nand read but as you see the length of the file is 0x4000 and the first 4 bytes are crc32 and that leaves 0x3ffc of data as you suggested --- End quote --- I would guess that command is not including the spare area, as that is stored at a "lower level" on the flash and is usually not used by applications. Every page is actually 0x840 bytes long. the last 0x40 bytes is typically used to store meta data (bad blocks, ECC information, etc) and is usually invisible for higher-level operations. Looking at the code, I see what appears to be some software-implemented ECC check that is operating on the spare pages, just before the program decides to throw up that block read failure. My guess is that data is not checking out, and causing the PBOOT to report a failure, despite the data actually being good. UBOOT may not be implementing this check. |
| Navigation |
| Message Index |
| Next page |
| Previous page |