MicroHacker Forum

DGAlexandru wrote: ↑18 Aug 2019, 10:53 The EEPROM .... holds security information (number of PIN tries or if the PIN is active or not) ....

Well, i read out the EEPROM with PIN enabled and after disabling the PIN. Both have same content, no difference

Unfortunately i need to desolder and resolder the EEPROM every time i want to read it... to do in-place, something disturbs the reader (i use RT809h). Maybe we find another way doing it via JTAG or some other Debug-Port of the V850.

Hmm.. OK .. sorry for misleading you. I had one MCA a long time ago which was locked because of too many bad PIN attempts and this is what I was remembering.
.. and it also sounds plausible to have this kind of data written on an EEPROM instead of doing it in the S29GL Flash for which it would have to first erase that sector in order to be able to write to it (unless they did a smart trick and go from "FF" to "00" by writing only "0" over "1" and never try to write "1" over a bit that has the "0" value stored in it).

When I want to try different settings for an EEPROM I cannot read on PCB I use a "hardware hack" - I install with wires a 8 pin DIP socket and then I solder the EEPROM on a small PCB that has pins for that 8 pin DIP socket. This way I can move the EEPROM from the target device to my programmer and back (very usefull for AirBag crash data "Full and locked" removal ).

I see you like playing with dissasembler.. so I've attached the BL (sector 0) of the NX DVD that failed to update. As you can see, it has at the begining the "normal" SP5.3 BL with some bits changed - and after it is this "update BL" part.
This NX DVD had 07.08.16.21 version for the Main Software, whereas SP5.3 has 10.04.29.16 version.
Another difference is that from 0x7FFE0 till 0x7FFFF on the failed one I had only FFs - maybe because it failed the update and this bits are for some kind of checksum.

Go4IT wrote: ↑18 Aug 2019, 15:02 I wonder if this could not also be done by pure software. The /EMIFS_WP pin may be controllable by manipulating IO-Registers of the OMAP and we could add it to the J-Flash init procedure like i did it for the Watchdog disable?!

GOTCHA!!

The datasheet states:

EMIFS interface includes WP output pin and provides full software control of it.
...
EMIFS Configuration Register (EMIFS_CONFIG) Base Address = 0xFFFE CC00, Offset = 0x0C
Bit 1 = BM Boot mode. Enables CS0 and CS3 address decoding swapping (See section 3.2.18 for BM reset value.)
0: CS0 [0000:0000 − 03FF:FFFF], CS3 [0C00:0000 − 0FFF:FFFF]
1: CS0 [0C00:0000 − 0FFF:FFFF], CS3 [0000:0000 − 03FF:FFFF]
Bit 0 = WP Write protect output pin control
0: WP output pin is set low.
1: WP output pin is set high.

So i simply added:
Write32 0xFFFE CC0C => 0x01000013
to the Segger MCU init procedure right before "Disable MMU" and i can erase and write the sector 0 as i like !
No desoldering needed any more!

With this last step we are now able to read and write the WHOLE flash!!!

DGAlexandru wrote: ↑18 Aug 2019, 21:36 Hmm.. OK .. sorry for misleading you. I had one MCA a long time ago which was locked because of too many bad PIN attempts and this is what I was remembering.

No worries pal, i believe you, but could not reproduce it. Maybe i fetch one of my play-FXs and put it to PIN locked state by entering false ones three times in a row and then see what happens in the EEPROM. There still should be a change after the first wrong attempt.

DGAlexandru wrote: ↑18 Aug 2019, 21:36 When I want to try different settings for an EEPROM I cannot read on PCB I use a "hardware hack" - I install with wires a 8 pin DIP socket and then I solder the EEPROM on a small PCB that has pins for that 8 pin DIP socket. This way I can move the EEPROM from the target device to my programmer and back (very usefull for AirBag crash data "Full and locked" removal ).

Absolutely right man, i thought of this in the same moment. Better than constantly de- and resolder. And, you can also watch the signals using an logic analyzer, too.

DGAlexandru wrote: ↑18 Aug 2019, 21:36 I see you like playing with dissasembler..

Yes, you are right with "playing". I'm still learning how to use it. I have some low level programming skills, but still no big clue about ARM. Used to do Z80 in the early 90th So ANY help is greatly appreciated here! Please feel free to give tips and hints how to disassemble using IDA in the subforum i made for it, or the disassemble satnav thread.

DGAlexandru wrote: ↑18 Aug 2019, 21:36 so I've attached the BL (sector 0) of the NX DVD that failed to update. As you can see, it has at the begining the "normal" SP5.3 BL with some bits changed - and after it is this "update BL" part.
This NX DVD had 07.08.16.21 version for the Main Software, whereas SP5.3 has 10.04.29.16 version.
Another difference is that from 0x7FFE0 till 0x7FFFF on the failed one I had only FFs - maybe because it failed the update and this bits are for some kind of checksum.

I try to understand what you want to tell me, but shure you are on a higher level...
All we do now here is "ground work", trying to understand how things work. For me, i want to know why some of my units won't boot. There must be any glue about it in the code or in debug/log output which may be send anywhere on an UART or such. A real big goal for me was to debug with the unit attached or to get some code running under QEMU.

Oh, there is so much to learn about those units, and for me it's a real fun!

Go4IT wrote: ↑18 Aug 2019, 22:23 I try to understand what you want to tell me, but shure you are on a higher level...
All we do now here is "ground work", trying to understand how things work. For me, i want to know why some of my units won't boot. There must be any glue about it in the code or in debug/log output which may be send anywhere on an UART or such. A real big goal for me was to debug with the unit attached or to get some code running under QEMU.

Oh, there is so much to learn about those units, and for me it's a real fun!

Or is because I don't know either and what I'm saying makes no sense )
I also have very little experience with disassembly.
Regarding the programming part I have some experience with low-level programming of PICs from Microchip.. but those are much simpler devices so they're much simpler to "debug" when you don't have the sources of the software that is running there; other than this I also like playing with "software development" but only as a hobby and do stuff that only do what I want with no appealing graphical interface

For me it's much easier to understand at hardware level and do a hack there. I never thought of looking into OMAP's datasheets to see if I can control that WP pin... so GOOD WORK for going that way!
I've registered to this forum because you helped me more with JTAG-ing this devices and I saw that someone has the same problem I had with that failed FW upgrade and I wanted to give some knowledge back.

In the past I tried to understand how OMAP communicates with Altera in order to try to have another device act as Altera and so have another device to drive a display. The ideea was to have an Android tablet instead of the display and a microcontroller acting between the tablet and OMAP in order to be able to still use the main board of NX. Raspberry Pi could also be a solution, but you don't have the Play Store goodies
I tried this with Ford Denso audio systems (https://www.youtube.com/watch?v=K9uHK2-vbhM just an Android tablet and an ELM327 connected to it over USB; the App was doing also the CAN BUS decoding and sending of commands), but there was only CAN messages to deal with as the audio system was built modular and all the modules were communicating over CAN BUS - like it's happening again with newer Ford cars.

I think it is very easy to have something written and boot OMAP with it and drive a LED, but to control everything on the board would be something very hard to do.
I also have some NX units that boot then restart, but I gave up on trying to repair them.

Sound great and i think we are absolutely on the same track. What do you think, should we make a list of all problems we encountered until yet and try to find ways to solve them? I still got some units with issues i couldn't fix until now, there are many thing that can go wrong. I would start with some and have created a subforum called "Repair" for this.

Using the unit as a headless system may be a good plan. Much better than those cheap China MCA clones, all working badly. Maybe we could share CAN knowledge, as i also have comprehensive information on it, but didn't do anything with it right know.

For the OMAP and Altera (Mainboard vs. Grahpicsboard) there is much to learn. From the construction it seems to use the graphicsboard like an LCD panel driven with commands rather than scanlines and pixels. One reason for that is, that if you mix panels and mainboards of different firmware versions, the display shows wrong strings. So i expect there is a command the OMAP sends to the board to show string ID something at position x,y in font blabla, rather than rendering the whole image and send the pixeldata to the graphicaboard.

I also figured it out that OMAP sends mainly only instructions to Altera on what to put on the display, but at the same time, the DVD / SD card with navigation data is read by OMAP in NX (in FX is read by Altera) and sent to Altera, and also RDS data / CD-audio / MP3 info / SRM BT "text" is also send by OAMP to Altera so there is also some data sent between them.
Having this comunication "decrypted" can lead to interesting upgrades

In terms of repairing them.. I usually don't have time for such time-consuming projects The one with failed FW update I had to repair as I was the one who tried to update it in order to make it work with a Stereo SRM (PN starting with 8 or more) for a client that wanted this kind of BT module... and it took me 16 hours in order to have it fixed as explained earlier in this topic

Go4IT wrote: ↑18 Aug 2019, 22:12

Go4IT wrote: ↑18 Aug 2019, 15:02 I wonder if this could not also be done by pure software. The /EMIFS_WP pin may be controllable by manipulating IO-Registers of the OMAP and we could add it to the J-Flash init procedure like i did it for the Watchdog disable?!

GOTCHA!!

The datasheet states:

EMIFS interface includes WP output pin and provides full software control of it.
...
EMIFS Configuration Register (EMIFS_CONFIG) Base Address = 0xFFFE CC00, Offset = 0x0C
Bit 1 = BM Boot mode. Enables CS0 and CS3 address decoding swapping (See section 3.2.18 for BM reset value.)
0: CS0 [0000:0000 − 03FF:FFFF], CS3 [0C00:0000 − 0FFF:FFFF]
1: CS0 [0C00:0000 − 0FFF:FFFF], CS3 [0000:0000 − 03FF:FFFF]
Bit 0 = WP Write protect output pin control
0: WP output pin is set low.
1: WP output pin is set high.

So i simply added:
Write32 0xFFFE CC0C => 0x01000013
to the Segger MCU init procedure right before "Disable MMU" and i can erase and write the sector 0 as i like !
No desoldering needed any more!

With this last step we are now able to read and write the WHOLE flash!!!

Hi go4it
As i just go me segger back with a new regulator fitted cant beleive they mended it, i thought they would just replace it.. anyway can you send me the
compleated init string for flash and ill dig out the old NX and try ,, if goes ok. i can help your friend we spoke of.
its great to see so many clever guys togeter certainly gets results

Hello!!!

After my summer vacations i return to my hobbies, i read new answars in this post a try new steps.
i remove the 0 ohm resistor and try to erease and write, the erase process work fine, but dont write my omap.
i take 2 screenshots with fails.
I have a bad ram memory? any sugestions?

Did you read back after erase to ensure the sector was all 0xFF ?
Working with the Flash would do even with RAMs desoldered (i told a while ago, you remember?)
Also try to keep JTAG wires as short as possible and try not to use those cheap Dupont-Wires. Make yourself a good ribbon cable to directly plug into the Segger on one side and a Micro-Match plug on the other. I once had strange problems too, until i switched to a custom cable.