(SOLVED!) How to read and write mainboard Flash (Spansion S29GL)

[Go4IT]

Hello, i have news. i follow all steps to dowload software, and connect unit. i made a back up of my 2 dvd units.
but when i try to write have a problem

The message states that you try to write a datafile which is bigger than the flash, or the number of selected sectors of it, you choose. Go into project settings and check on the flash tab what is selected (S29G512N) and first/last sector settings (compare with the screenshots of the Wiki article i linked above).

Keep warned that you need to erase the flash prior to programming. Erasing means that all bits set to '1'. Do this first, then re-read to check if its done on all sectors. Note that sector 0 is neither erase- nor write-able via JTAG. It seems chip-protected.

[oscarboiro]

I have the same configuration of instructions, and have selected a S29GL512N.

I try to erase and have next fail:

Erasing Fail.jpg

this unit fail after update with wrong software, is possible damage de omap? or i need triyn another options and configuratios?

thanks!

[oscarboiro]

i read voltaje in the bridge of points 3 - 13 and have 0 volts, is normal? or i neer 3,3V?

[Stevebe]

This may seem strange but I am getting the same results, I cant erase flash same error.
I was beginning to think my mobo faulty but how can we have similar problems,
I have taken the mobo out of the NX so no other connections, made no difference,
I’m not certain what to try

[Go4IT]

Erasing a flash is practically the same as writing just 1s to it. So if you can erase a sector you should also be able to program it.

Try to erase arbitrary single sectors, e.g, number 43, or 185, or something other. Avoid using sector 0. To do so go into the project settings, choose flash tab and select the individual sector using the "start addr" and "end addr" dropdowns in the lower left. The choose "erase selected sector" from the menu.

This should work!

If some sectors deny to erase or program, you may should reflow the chip, because BGAs tend to get cold solder joints. Thanks to leadfree solder...

[Go4IT]

I try to erase and have next fail:

Even if doing anything right, this error occurs. It seem to have a time component, means that it do for some time and then fails. Sometimes one could erase/flash up to 30 sectors without an issue, but other ranges can only be programmed with a few sectors at one. It seems arbitrary. This may be caused by the fact that programming/erasing is not a linear process. For example: if you erase a single sector which contains data, this process take some time. If it is clear and you erase it agina, it is just like "boom - finished". This is because of the nature of the flash and also the optimizations of Seggers J-Flash software. If all the bits are set to '1', there is no need to do it again. You get this if you successfully erased a chip and do the process again. The second run will be finished in seconds, whereas the first run needs minutes, and even now multiple iterations.

J-Flash first HALT the CPU, then "downloads" a piece of software into the SRAM of the OMAP and executes it. This software (i call it an "exploit") accesses the flash directly, parallel by the OMAP IO-lines and sends the data back and forth using the JTAG-protocol (serial). This piece of software gets interrupted somehow and therefore the errormessage appears, because communication get lost. This is also reflected by the current drop you can read on an amperemeter or the display of the power supply.

As long as the radioprocessors watchdog is active, i understand that it aborts after 12 seconds from the moment the CPU is halted. But by chilling the watchdog with grounding pin 13 of serviceport 2, erasing and writing should work like reading. Technically i see no difference, and have no clue why and what is interfering here. Maybe what we are faced is a software error of the J-Flash exploit, we should not push this to far away, even if it sounds unlikely. But there are also watchdog components on the OMAP, namely the CoProcessor (CP15) and the Memory-Management-Unit (MMU) of the CPU itself. Maybe they get triggered by writing to the flash only...

What makes me think that there is another component (namely a watchdog) interrupting the process is that the PC (program counter) seems always to be "0x0000 0000", which is the boot-sequence. I attached two more errormessages from programming aborts i get, which also shows this correlation.

We should dig deeper into what the messages tells us and what all those register values mean!

[Go4IT]

I've attached an NX board to my Segger and do some tests. I have build a small dash where i mount a reset-push and some switches onto and connect this to the second service port of the NX. There i can switch on/off the /SEL (Tuareg mode) and also issue a hardware-reset to the board.

I set start addr is set to sector 0 and end addr to sector 511 in "Flash" tab of project settings in J-Flash. Then i press "F4" ("Erase entire chip") right after i released the reset button and the erasing begin. I counted the seconds until it aborts. I've retried this many times to proof for evidence. After 20 seconds the error occures. So there is definitively something resetting the unit (watchdog). I'll try to catch this by surveille the RESET line of the OMAP and the V850 if i can see this there, but maybe it's an internal reset of the OMAP and i must read the datasheet if this is also reflected outside somewhere.

Ok folks, let's find this 20s bastard and give him a kick!

[Go4IT]

So, yesterday i trie to dig a little deeper into our problem (which should be discussed in another thread called "How to write to mainboard Flash") but didn't get any further. I try to find out if the V850, which seems to control the powerdistribution on the boards components, is cutting off the Flash or OMAP after the 20s or issues an reset.

To get back to topic, i also have another faulty unit here on the desk. It doesn't turn on, but draws about 350 mA, so the RAMs seem ok. I'd like to reflash, and first read back the contents to eventually restoree i later. When reading, even with /SEL to GND, it aborts after 20s! Argh. Maybe our issues are related. Only chance is to read chunk by chunk. Because the number of sectors which fits into 20sec of reading belongs to their content, its alway a trial-and-error method o find how mucht can be read back. I use a opportunistic method, just set the end sector high, wait until it crash and set the end sector to the sector before the crashing sector. This is the maximum it reads. Dump and easy. But this takes half an hour to read back a device ;-(

[Go4IT]

i was having the same problem, but now it keept stoping at 32% saying MCU was running.(the WD linmk is on) ..
then it started to get to 52%. but fails at the address seen on capture

I thought i mentioned this problem before... well, for some reason i do not know for now (hopefully we get around this some time), there seems to be another watchdog involved. To burn the whole image you need to do it in chunks. So we start with sector 1 to 25. Select them in the Flash tab of the project settings. Note the addresses. Then use the menu entry in J-Flash to delete the first sector bytes from the image. Next, try to flash using "program selected sectors". Go on with sector 26 to 50. and so forth...

[Go4IT]

According to the datasheet, there is a signal on OMAP called "/RST_OUT" (pin G23) which seem to pulse when the MCU is issuing an internal reset. Also two other signals, "/MPU_RST"(pin H23), which seems to be generated by that "MAX6389" reset-circuit-chip and "/POR_RST" (pin J23), again generated by a Maxim chip of the same type.

We should check if they are somehow related to our problem.

I've traced them down on the board to measure points (i love those PCB facturing testing points, they help so much and draw a picture where they are located.

nx_mb_btm_mps.jpg

Note that the board i use for this tests is a "1275D09". You find the board revision on the lower left of the picture attached.