Page 4 of 11

Re: How to dump content of mainboard Flash (Spansion S29GL)

Posted: 27 Feb 2019, 05:56
by Go4IT
I should point some things out, just that we head into the same direction ;)

First, there is no difference in firmware for unit with or without camera input, so you can mix like you want.

Next, the goal of all rescue methods we try here is to bring the unti back to live, just to be able to run an Firmware update from CD. This is needed because if you flash an arbitrary Firmware on the device and it does not match the firmware of the graphics board, you get strange results on the screen.

And last, please make shure you understand how flash chips work. Also, you should know about adressing and hexadecimal value system.

Well, a little crash course in Flash chips is sogned, i guess: Think of Flash like the good old EPROMs, but only ways faster. With programming you can only draw Bits to logical 0. Therefore they need to be set to 1 first. This is done by erasing. So you can't just simply "overwrite" the content of it, you must first erase it.
Flash chips are organized in sectors, so,you can't random access a single Byte/Word in it's memory to erase. Each sector has an logical number, which represents an address, if counted from 0x0 on the beginning of the chip. The start address is in fact only how the using system, here the CPU sees it, but we assume it starts this way.

Hope this clears some points.

Re: How to dump content of mainboard Flash (Spansion S29GL)

Posted: 01 Mar 2019, 12:14
by oscarboiro
Hello! Thanks! Last days I read some articles to write memory etc etc and now I know my fail.

This weekend i try to restart all process, complete erease and write step by step.

I hope to recover my unit, when I have any result I write in this post.

Thanks!!!!

Re: How to dump content of mainboard Flash (Spansion S29GL)

Posted: 01 Mar 2019, 17:02
by oscarboiro
i can not waitt more!!!!

i had a little free time and try to write, and WORK!!!!!
CD00DEA9-7AF1-488D-B8FE-B9D1B00A2E73.JPG
after write the backup from my NX withouth rear camera work fine, only need put the pin code of the other unit.
to solve the pin problem, i rewrite 507 sector, i follow your post to pin code, and recover this sector from the backup of nx with rear camera.

now work with his own pin.

after test all menus, i put the nx sp3.5 to aply complete software, but after intalling, now dont work the buttons of the NX.
3C5ECCEF-8054-41A3-AD9A-D2F1348DB4F3.JPG
i think, after write backup of nx withouth rear camera, is possible write any number of software or part to grapics card? i thing, after update, put a wrong software in graphics card.

any user have a backup of a nx with rear camera to try to upload in my unit, and later update to sp 3,5 and try to recover my buttons?

if i put the screen with graphics card of nx withouth rear camera, the buttons work fine :roll:

Re: How to dump content of mainboard Flash (Spansion S29GL)

Posted: 01 Mar 2019, 20:30
by Go4IT
Weird. So, if i get you right after you flashed the faulty unit with a dump from a working unit, everything seems fine in the first. Then you copied the sector 507 over from originate unit to retrieve old pin from unit. And after doing an SP5.3 update, there is something wrong?
Could you power on the unit using the on tipper?
Could touch be used (enter pin and such)?
Did you watch the update running all the time?
As a very last step the graphicsboard flash get updated. This is shown in a different manner than the mainboard update (other, simpler graphics, looks more than an text console).

The keys are controlled by the graphicsboard, except for the eject-key and the on-tipper.
Don't worry about the video function, there is no special video/non-video firmware, it's all the same. Firmwares only differ in version.

I can image that there may be something wrong, but can't sort it out. I don't managed to read/write the graphicsboard flash. Now this is currently an unsolved problem we should discuss in another thread...

Re: How to dump content of mainboard Flash (Spansion S29GL)

Posted: 02 Mar 2019, 14:28
by Go4IT
As i reflashed a NX and read it back right after flashing (held /SEL down all the time, programming board only, without display attached) i found that both image differ. That i did'nt expect. In areas where the image flashed had 0xFF, the readback contains data. I'm not shure if this is because the Flash chip is broken or the current flash method.

I should really do an readback of the Flash after erasing it, because it seems that erasing function of Segger J-Flash does not valide this itself. Some time ago a had an NX for repair and it does not erase some bytes or sectors. When programming i get errormessage "cannot write 1 over 0" which tells me that the bit i try to program was not erased. After rework the chip with hot air gun, the sectors in question could be erased successfully. Similar with an NX having defective RAMs, the flash could not be erased, it always produced aborts.After replacing the RAMs, all works fine. On the other hand, a unit withou RAMs can be programmed all fine.

I suspect the /SEL signal to only void watchdog-resets from the V850. Maybe there is something running on the HMI which also fill the Flash.

Re: How to dump content of mainboard Flash (Spansion S29GL)

Posted: 02 Mar 2019, 15:18
by oscarboiro
Hello.

I go to explain my experience with my NX unit and later talk from we conclusions.
Some time ago, when i don´t found any information of this unit in internet, i put the screen with her screen pcb in my nx with rear camera. i think to change screen to test the fault in my unit, bad screen pcb or bad mother board pcb. the result is unit withouth rear camera work fine.
after this test, i forget return the screen with grapichs pcb to correct unit and save all units in my loft.
some time later, i give the motral software to use recorded DVD, and take my NX withouth rear camera in my loft and try to install.
After install dont work the buttons, only work power on button, dont try ejecj. in this moment i remeber the unit have a wrong grapics card.
i return to correct graphics card and update software, the NX withouth rear camera later works fine with correct graphics card.
after looking the graphics cads, i see different graphic controler, the NX withoth rear camera has Cyclone and nx with rear camera has Cyclone II
the MCA has Cyclone III

My first conclusion: when update unit write different software to graphics card ¿depend of any serial number to detected different cards?

Some time later i find good offer of graphics pcb, and i buy it , always i have hope to recover this unit and i thig to buy this part and save it.

Now following the instructions of monbdeo wiki, i decide to buy a serger programmer, after long time stoped in my loft, now thanks to Go4IT i found this forum with fantastic information and i try to recover unit, and yes, after write memory the unit survive, i use the new graphics pcb and work all buttons.
next steep i think to install service pack 3,5, after install repeat same problem, my unit loose the buttons, only work power. in this moment i remember the same problem of the past and i decide replace sector 507, i see part number in this sector, curiously i flash with unit turned on and work fine, after replace 507 sector i try to install another time the SP 3.5 but dont recover the buttons.

My conclussion is, i think any sector more have information or any reference to detect Cyclone or Cyclone II or another difference in the PCB, but i don´t know. now i think to put a backup of a NX with rear camera and Cyclone II chip and try to Install SP3.5

The touch screen work fine, i put the pin code and i possible change radio stations.

some pictures:
IMG_7589.JPG
DC46AB08-3A22-41B7-A13B-2546DCB53A43.JPG
D81F2B42-BC72-4B03-94AD-F0C47205D088.JPG
CD00DEA9-7AF1-488D-B8FE-B9D1B00A2E73.JPG
3333E9B3-A5D1-43B2-852C-DC3DBDAF2D54.JPG
2073D3BF-D9A9-4348-A823-B8C2EE169E1C.JPG
3C5ECCEF-8054-41A3-AD9A-D2F1348DB4F3.JPG

Re: How to dump content of mainboard Flash (Spansion S29GL)

Posted: 02 Mar 2019, 16:03
by Go4IT
Please all not the added filename conventions for Flash dumps in the first post of this thread!

Re: How to dump content of mainboard Flash (Spansion S29GL)

Posted: 02 Mar 2019, 16:29
by Go4IT
I unsoldered the RAMs from my faulty NX because i suspect them to be broken.
As they are removed, i just tested and found out that the Flash can be read/erased/written completely without RAMs applied to the board ;)
Funny stuff. May of no use, but interesting. It tells us that the RAMs are not necessariliy needed to access the Flash. They may be broken, or missing.

But what stays is this dammned 20 secs abort. :x

Oh, i made another discovery i should tell you! :D
On pin 5 of the rightmost service-port there is a /MAN_RESET signal:
mainboard_serviceport2_pinout.jpg
If one apply GND here the HMI processor reboots.

I connected to pin with pin 15 of the Segger J-Tag connector:
segger_jlink_pinout.png
and prepend the MCU init sequence with an "Reset" command:
mcu_add_reset.png
It will issue an reset each time you read/erase or program the Flash:
nx_jtag_reset.png
Very helpfull, because you don't need to push the reset-button all the time ;-)

Re: How to dump content of mainboard Flash (Spansion S29GL)

Posted: 02 Mar 2019, 20:08
by Go4IT
oscarboiro wrote: 02 Mar 2019, 15:18 My conclussion is, i think any sector more have information or any reference to detect Cyclone or Cyclone II or another difference in the PCB, but i don´t know. now i think to put a backup of a NX with rear camera and Cyclone II chip and try to Install SP3.5
I agree that there is some gap we need to look after. I told you about my faulty NX to repair. It had the well known restart loop syndrome. Powers up and after 20 seconds (arg, here they are again!) it switches off and restarts over again. I thought "an easy fix, just reflash". Of course i first backuped the Flash to have also sector 507 for later. Then i flashed one of my working NX dumps on it, and it boots up like a charm. All fine, i thought and started the regular SP5.3 Firmwareupdate. I let it run as it looks fine. After it is finished the unit restarts and goes into sleep mode. Normally it can be revoked by pressing the ON-tipper, but nothing happened. Since then i try to recover it.

So, it's similar to your problem, just with another dimension. You "only" use button control (which i never ever heard before) and i use the mainboard. It draws about 100 mA at 14V and i could access the Flash so far. Tried to erase and program different images multiple time whith no luck. Of the powerdraw it looks like the HMI had an software crash or such. Just to be safe i also replaced the RAM chips, but this does not help either.

The unit i have here to fix has part number "7S7T-18K931-BL" (Bosch 7 612 300 534). The original MAIN_VER_SW was "0843_090128" (date 28.01.2009) a very old firmware. The REG_VERSION was "DI_SWNAVI6.4C1P7.3", but i guess it's only relevant for navigation application. The software on the graphicsboard shurely fits to this somehow. After an update they are both changed, of course.

Another thing that keeps my attraction was, that it's not possible to write the first sector 0, it seems readyonly for the Segger. This may be ok, because it contains the bootloader of the system. Without it, or with an damaged one, the unit can't start anymore. But as i found out, after an update to SP5.3 it changes content. The update software seems to be able to unlock and overwrite the sector. The bootloader software is given in the PSW software version, found inside the flash.

The original flash starts with: "D3 02 00 EA 05 00 00 EA 05 00 00 EA 05 00 00 EA"
whereas after the update: "CE 07 00 EA 05 00 00 EA 05 00 00 EA 05 00 00 EA"

For now i beliefe the OMAP starts like every other CPU from address 0x0. I know it executes the software rights from the NOR flash, like a ROM. So what could this mean? I think this is simple ARM9 machine code. The repeating pattern looks like this is a vector area, where external and internal interrupts set the PC to a location and executed from there. If i put the line into ODA i get this Assembler code:

Code: Select all

                           .data:00000000 d3 02 00 ea                      b	0x00000b54
                           .data:00000004 05 00 00 ea                      b	0x00000020
                           .data:00000008 05 00 00 ea                      b	0x00000024
                           .data:0000000c 05 00 00 ea                      b	0x00000028
and from the second one:

Code: Select all

                           .data:00000000 ce 07 00 ea                      b	0x00001f40
                           .data:00000004 05 00 00 ea                      b	0x00000020
                           .data:00000008 05 00 00 ea                      b	0x00000024
                           .data:0000000c 05 00 00 ea                      b	0x00000028
Let's just look on the first command, 'b'. The ARM Assembler Reference tells us this about it:
arm_b_bl_instruction.png
Always remember: ARM uses Little-Endian (bytes read from right to left) and 4 Bytes (32 Bits) per instruction. So if we translate the byte sequence "d3 02 00 ea" into Bit-Endian we get "ea 00 02 d3" which in Binary shown as: "1110 1010 0000 0000 0000 0010 1101 0011".
From left (Bit 31, or MSB) to right (Bit 0, or LSB) we have:
"1110" = "cond", this pattern means "AL" (always, or unconditional branch).
"101" = denotes the Mnemonic 'b' for branch (referred in other Assembler languages as jump or jmp)
"0" = "L", means to not store a return address into register R14.
"0000 0000 0000 0010 1101 0011" = "target address", which is an offset to the current program counter register PC. In hex the offset is "0x2d3".

Now, we CAREFULLY read what is written as target address calculation.
1. the value (0x2d3) is extended to 30 bit, which leaves it 0x2d3.
2. the 30 bit value is shifted the left by two bits to form a 32-bit value. So 0x2d3 gets "0000 0000 0000 0000 1011 0100 1100", which means 0xb4c.
3. PC is added to the value. PC always points to the next instruction. Because each instruction is 4 Bytes in size, the PC is 8 Bytes ahead from the offset given in the command. This has to be added. So we have 0xb4c + 8 = 0xb54

One conclusion here is, that a "b" instruction does not get an abritrary memory location, it gets and command location. This is a neat trick to avoid wrong calculated branches to illegal offsets. Think about it, even if it takes some time, you see it's totally locical. BTW: a bitshift by 2 is equal to a mulitplication with 4. So as an shortcut to read hexdumps, the first two bytes (turned around) multiplied by 4 plus 8 bytes results in the target address of the branch.

At 0xB54 on the first bootloader we find:

Code: Select all

00000b54 d3 00 a0 e3                      mov	r0, #211	; 0xd3
00000b58 00 f0 21 e1                      msr	CPSR_c, r0
00000b5c bc 07 9f e5                      ldr	r0, [pc, #1980]	; 0x00001320
00000b60 00 10 90 e5                      ldr	r1, [r0]
00000b64 b8 27 9f e5                      ldr	r2, [pc, #1976]	; 0x00001324
00000b68 02 00 51 e1                      cmp	r1, r2
00000b6c d7 01 00 1a                      bne	0x000012d0
00000b70 b0 07 9f e5                      ldr	r0, [pc, #1968]	; 0x00001328
00000b74 01 10 a0 e3                      mov	r1, #1
00000b78 14 10 80 e5                      str	r1, [r0, #20]
00000b7c a8 27 9f e5                      ldr	r2, [pc, #1960]	; 0x0000132c
00000b80 00 30 92 e5                      ldr	r3, [r2]
00000b84 0e 28 a0 e3                      mov	r2, #917504	; 0xe0000
00000b88 02 20 13 e0                      ands	r2, r3, r2
00000b8c 15 00 00 1a                      bne	0x00000be8
and on the second one at 0x1f40

Code: Select all

00001f40 d3 00 a0 e3                      mov	r0, #211	; 0xd3
00001f44 00 f0 21 e1                      msr	CPSR_c, r0
00001f48 bc 07 9f e5                      ldr	r0, [pc, #1980]	; 0x0000270c
00001f4c 00 10 90 e5                      ldr	r1, [r0]
00001f50 b8 27 9f e5                      ldr	r2, [pc, #1976]	; 0x00002710
00001f54 02 00 51 e1                      cmp	r1, r2
00001f58 d7 01 00 1a                      bne	0x000026bc
00001f5c b0 07 9f e5                      ldr	r0, [pc, #1968]	; 0x00002714
00001f60 01 10 a0 e3                      mov	r1, #1
00001f64 14 10 80 e5                      str	r1, [r0, #20]
00001f68 a8 27 9f e5                      ldr	r2, [pc, #1960]	; 0x00002718
00001f6c 00 30 92 e5                      ldr	r3, [r2]
00001f70 0e 28 a0 e3                      mov	r2, #917504	; 0xe0000
00001f74 02 20 13 e0                      ands	r2, r3, r2
00001f78 15 00 00 1a                      bne	0x00001fd4
No really a difference, just in memory location :-)

Conclusion: The old bootloader code starts at address 0xb54, and the new bootloader code at address 0x1f40. This is not a problem at all, because the bootloader seems to be fully contained within the first sector. But if the data in the second sector (and following) is also somehow other aligned, this may cause problems.

Re: How to dump content of mainboard Flash (Spansion S29GL)

Posted: 03 Mar 2019, 07:49
by oscarboiro
Good morning.

Yesterday I put another software in my NX, thanks to Go4IT to send me it.
After replace software I start the update with SP5.3 and is curiously the message “eject SD card” my unit have a DVD.
DDA23657-7AF1-4DC1-A27E-4D940D0B27CE.jpeg
After update don’t solve the problem in the keys.
Now I have next questions?

This software comes from unit with graphics card Cyclone or cyclone II?

It’s possible firsts versions of NX I know made in Germany, have a Cyclone and the units made in Portugal have Ciclone II?

It’s possible the units with cyclone have camera imput?

I think, to solve the problem with keys, first need know all configurations of main board And graphics card models.

I’m look the main board of NX without rear camera and have pre install rear camera circuit, I follow the wire in main board to graphics board, and after comprare with main board with rear camera, have diferent adress in the conector.
My nx without rear camera are from Germany and the nx with camera are from Portugal.

Any suggestions?

Best regards