Electronics > Repair
Agilent 34461A corrupted flash
<< < (18/41) > >>
ElectronMan:

--- Quote from: analogRF on July 30, 2023, 08:35:27 pm ---here it is

--- End quote ---

Thanks. That looks significantly different than mine.

I think what I am going to suggest is that you dump the entire block (64 * 2048 byte pages) starting at that 0xc0000 offset and then re-write exactly the same block back to flash if you can under the Uboot prompt.

Unless there is some actual physical flash damage, that should get the spare areas back in sync for the block.

Of course, this is taking a risk, so usual disclaimer here...
analogRF:

--- Quote from: ElectronMan on July 30, 2023, 08:46:17 pm ---
--- Quote from: analogRF on July 30, 2023, 08:35:27 pm ---here it is

--- End quote ---

Thanks. That looks significantly different than mine.

I think what I am going to suggest is that you dump the entire block (64 * 2048 byte pages) starting at that 0xc0000 offset and then re-write exactly the same block back to flash if you can under the Uboot prompt.

Unless there is some actual physical flash damage, that should get the spare areas back in sync for the block.

Of course, this is taking a risk, so usual disclaimer here...

--- End quote ---

oh no you looked at the wrong file, I messed up there and deleted that message already  :-[ :-[

please look at the bin file I just posted. change the extension to .bin

analogRF:
the file i posted earlier and you looked at was supposed to be this one here but I dont know what happened

it is just the plain text. Then I made a bin file from it and posted above

ElectronMan:

--- Quote from: analogRF on July 30, 2023, 08:49:25 pm ---
--- Quote from: ElectronMan on July 30, 2023, 08:46:17 pm ---
--- Quote from: analogRF on July 30, 2023, 08:35:27 pm ---here it is

--- End quote ---

Thanks. That looks significantly different than mine.

I think what I am going to suggest is that you dump the entire block (64 * 2048 byte pages) starting at that 0xc0000 offset and then re-write exactly the same block back to flash if you can under the Uboot prompt.

Unless there is some actual physical flash damage, that should get the spare areas back in sync for the block.

Of course, this is taking a risk, so usual disclaimer here...

--- End quote ---

oh no you looked at the wrong file, I messed up there and deleted that message already  :-[ :-[

please look at the bin file I just posted. change the extension to .bin

--- End quote ---

Looks the same. (I had taken the text and copied it into my hex editor to reproduce it).

The disturbing thing is that looking at your boot process, it basically told you that every block up to the end of flash from there has the same issue, which points to possible physical damage.

I would still try rewriting that block and see if the error clears for that one, but you may have other errors if that fixes the boot config block.
analogRF:
it does not look out of ordinary to me

by the way, if i want to dump the nand and write it back into the nand in uboot
I cannot write into those out of band areas. "nand dump" dumps one page at a time with those oob
but nand write has no way of writing in those oob area unless they are calculated automatically and updated by the nand controller

in that case I can just read the data by nand read and write it back instead of sumping one page at a time
I am only concerned about nand write command because still I am not sure what is the third parameter
is it a page size or is it # of bytes or some other block size? that scares me  :scared: :scared:
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod