MicroHacker Forum

oscarboiro wrote: ↑03 Mar 2019, 07:49 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.

This is because the HMI does not seem to send full graphics images or texts to the graphicsboard, but more something like "Hey, GB, please place text with ID 0x65 at cursorposition 40, 3 centered, using font F in size S". So if HMI and GB firmware have different meaning of what is text ID 0x65 (just an example!) the GB places wrong messages to the screen.

oscarboiro wrote: ↑03 Mar 2019, 07:49 This software comes from unit with graphics card Cyclone or cyclone II?

Lets show pictures pointing this out. The boards of video and non-video are different with NX. They are both having Altera Cyclones II. Only the MCA GB has Cyclone III (just faster and such).
All development comes from Germany (BOSCH). Portugal is only a build facility. Where the unit is built has nothing to do how it behaves.

One thing i totally forgett, the EEPROM of the RU. I'm not really shure what it is used for exactly, but it may also keep information which is changed during an update. The "log"-messages i found may point to this: "X:\di_middleware_server\components\fc_tmctuner\Source\tun_Flash_File_Access.cpp". The message contains the source code part of where the error occures (standard GDB debugging scheme) and "tun" is the shortcut of "tuner". This throws an error in my case but it shows that "something" is trying to access this EEPROM from inside the HMI. Maybe this is read, maybe write, but somehow the software does not find what it expects.

This 8pin SOP SMD IC can be simply desoldered and read/programmed with a external Flasher. I've tried to read it in-place, but failed, so desoldering seems needed. But maybe i'm wrong, just test yourself. Unfortunately i've never backuped the content of it before doing anything with the radio. What i try to do now is to clone an older Firmware from a working device onto my faulty device and also clone it's EEPROM contents. Hopefully this will bring my unit back to life, as i suspect the EEPROM is made for lockdown the unit on errors or faulty PINs.

P.S.: Read out of EEPROM (after SP update and therefore may broken) attached.

I removed the original EEPROM from the faulty NX board, read it out and soldered a new one (unprogrammed, all bytes 0xFF) into the faulty NX - unit does still not boot. Then desoldered it again and read out, as i expect the unit to write something into. But all is still 0xFF, so it was not initialized by the system. Next, i programmed the new EEPROM with the content of the original one (maybe it was simply electrical broken) and soldered back, but no luck, the unit still does not start.

Next i do this with an working NX the same way, remove the original EEPROM, placed an unprogrammed onto it, and start - the unit comes up as usual, even PIN is ok. After desoldering and read back the EEPROM content is the same as of the original one. So the system itself initialized the content, if it's missing (or maybe all the time).

Conclusion: the EEPROM must be there, without it, the unit does not start. But the content is not relevant for booting and get's written if EEPROM is replaced by a unprogrammed new one.

Problem found: But i can agree that there is an issue when updating the reflashed NX with SP5.3. As i wrote i lost one NX after reflash and update to SP5.3. When i connect the frontpanel to my working NX, it does not turn on (even if the main HMI starts normally). No reaction on start button, display leaves black. Using another frontpanel and i immediately get an picture. So the update do something bad with the GB flash...

Because i programmed a lot today, i get also many errors and aborts. I guess there is some other software running and trying to access the flash, because it sometimes behave strange. Some sectors seem to morph after flashed. I get this because sometimes i'm too lazy to change the start sector when programming aborts. So i just hit F5 to reprogramm the whole range and expect the content is still the same, so the optimizing of the Segger will skip the sector and go on with the next one. This usually works well, but sometimes it will not ("cannot write 1 over 0" error appears). Then i hit "F3" to simply erase the currently selected sectors. When i do this the first time i expect the J-Flash to really erase, but on the second time if should determine that the sector is already empty and should skip erasing. It should, but it not always does. After a second "F3" it seems to erase the previously erased sectors again (most often one or two) and after "F3" for the third time, it passes like expected.

Problematic ranges seem to be 0x04A0000, 0x1600000 and 0x3FC0000. Especially the last sector (511) seems to be modified by the system. Erasing seems ok, but writing to it causes the system to go into deep sleep mode (12mA current draw). To recover from this mode fast, i unload the capacitors (using an low resistor and cable, to not produce too much current when shorting the poles). If not, you have to wait for 5 minutes or such.

Using the /SEL (Tuareg) mode seems not to prevent the HMI from running the software from Flash, if not in a programming session (CPU and MMU halted). When we programm the flash, i will abort after some portion is written. Then we need to reset to go on again. But after reset and before HALT the CPU again, there is enough time to run the portion of software still in place. Maybe there is enough software loaded to enable an OMAP internal watchdog register, which is not handled by the HALT routine of the J-Flash. This could also be the answer to the question what is changing Flash after programming.

Just a thought...

Guys, we need to figure out how to flash in one go, without aborts! If we ony flash a part and need to reset the OMAP to do the next run, it really executes what we programmed so far, because the CPU is halted later. This must lead to strange behavour... the fact that sectors gets changed between program cycles show this.

What i search for is how to prevent the OMAP from executing any software, like if it is held in reset mode, and leave this status if we are done with programming.

Good night.

I have a new problem, today after write complete software I put the disc to update. But when start update I loose the power.

Now to recover unit I try to write and show problem to connect, tomorrow I try onether time to write and take a screen shots.

Oh, you try it the hard way?! Well, depending on the stage of the update it should be possible to recover from here by just rewrite the flash using JTAG. I assume you got a powersupply which shows you the current draw. If it goes down to some mA (4-15) the RU has shutdown everything. This happens to me sometimes also, when programming over JTAG. To recover from here you need to unload the big caps, because they can keep the RU in sleepmode (or lockmode, don't know) for some minutes without external power.

Besides of the MB Flash, the update may to a lot more. For shure it also updates the GB Flash, we know, and even there is an EEPROM. But the RU processor itself (V850) has an internal Flash which may also gets an update. Same for the other modules on the board.

Good morning.

Today i try to write but have the same fail:
The process of write SP5.3 fail(loose power) around 20/30 seconds after start process.

oscarboiro wrote: ↑04 Mar 2019, 08:59 Today i try to write but have the same fail:

What about the current consumption? What does the Segger see for voltages on JTAG? Show initi sequence of log.

i finally got a new dvd tray from the mighty parts dept in China, fitted and all works well the bootloop cured unfortunately i could not
load Olivers fixed file, but if i know take a dump of the NOR ram and compair to the fixed file i would think they will be the same.