EmbeddedRelated.com
Forums

Where do I connect to the board?

Started by steff_dk November 9, 2007
Hi all.
I want to change the text labels displayed on my car radio to my native
language instead of English. I have been told that it operates a
Siemens/Infineon c167-crlm.

I have come to the conclusion that Rowley's CrossWorks and CrossConnect
may be a good choice - that is also within my economic reach (this being a
purely private hobby project).

But before throwing money at this - can I connect to the board at all?

It looks like this:
http://www.iamsteff.com/storage/001.jpg
http://www.iamsteff.com/storage/002.jpg

So far, this is my first travel into the realms of "embedded" ...
Any help or pointers will be highly appreciated!

Thx

Steff


"steff_dk" <jsteffensen@gmail.com> wrote in message
news:w_idnUA6k8OryqnanZ2dnUVZ_gudnZ2d@giganews.com...
> Hi all. > I want to change the text labels displayed on my car radio to my native > language instead of English. I have been told that it operates a > Siemens/Infineon c167-crlm. > > I have come to the conclusion that Rowley's CrossWorks and CrossConnect > may be a good choice - that is also within my economic reach (this being a > purely private hobby project). > > But before throwing money at this - can I connect to the board at all?
Even if you could, they've probably set some protections bits which will prevent you from downloading the code into Crossworks. You probably have to erase the entire chip too first before you can program it again. Meindert
> I want to change the text labels displayed on my car radio to my native > language instead of English. I have been told that it operates a > Siemens/Infineon c167-crlm. > > I have come to the conclusion that Rowley's CrossWorks and CrossConnect > may be a good choice - that is also within my economic reach (this being a > purely private hobby project).
Correct me if I'm wrong, but to my knowledge CrossWorks does not support the C167. -- Regards, Richard. + http://www.FreeRTOS.org 14 official architecture ports, 1000 downloads per week. + http://www.SafeRTOS.com Certified by T&#4294967295;V as meeting the requirements for safety related systems.
>Even if you could, they've probably set some protections bits which will >prevent you from downloading the code into Crossworks. You probably have
to
>erase the entire chip too first before you can program it again. > >Meindert
Well, I do have the firmware running on it now, on a CD as well. Maybe a more suitable solution is to change the firmware and then flash it. Does anyone know if the firmware is manipulated during install, or if it is just copied directly from the cd to flash memory in this process? Can anyone recommend some litterature/webpages etc. on flashing a device? Thanks!
steff_dk wrote:
>>Even if you could, they've probably set some protections bits which will >>prevent you from downloading the code into Crossworks. You probably have to >>erase the entire chip too first before you can program it again. > > Well, I do have the firmware running on it now, on a CD as well. > Maybe a more suitable solution is to change the firmware and then flash > it.
If this were a device I made the bootloader for, all you would have now would be a CD full of seemingly random bytes, which would also be protected against tampering by several checksums. Checksums are required to detect failed updates or otherwise broken flashes, and encryption came as a useful side-effect to compression.
> Does anyone know if the firmware is manipulated during install, or if it > is just copied directly from the cd to flash memory in this process?
The manufacturer of your device knows. I would consider a unverified 1:1 copy rather unusual. The minimum is some checksum and control (=which device is this firmware for, at what address in the flash does it go, etc.) headers. Okay, you *may* be lucky and find the strings somewhere, but if you have to ask where to connect, you still have some way to go :-) Stefan
On Fri, 09 Nov 2007 06:48:54 -0600, "steff_dk" <jsteffensen@gmail.com>
wrote:

>Hi all. >I want to change the text labels displayed on my car radio to my native >language instead of English. I have been told that it operates a >Siemens/Infineon c167-crlm.
Wrong. It's a NEC controller: UPD70F3079AYGC Look here for further info: http://www.necel.com/cgi-bin/nesdis/o002_e.cgi?article=UPD70F3079*&langcode=E And yes, the controller does have In-System Programming capabilities. There might be lock bits for ip protection, however. You'll need the special NEC development tools for that. Mit freundlichen Gr&#4294967295;&#4294967295;en Frank-Christian Kr&#4294967295;gel
>Okay, you *may* be lucky and find the strings somewhere
I am lucky! ;-) Strings are in this file from the firmware (on the cd for flashing): www.iamsteff.com/storage/VMEG0411.DNL It's a straight forward file as I see it in winhex: www.iamsteff.com/storage/winhex_scr_dump.gif First 32 bytes are excluded from the checksummed data - the the first checksum 4 bytes: x00 x60 x00 x38 then 56 bytes of data and then next checksum incremented to: x00 x60 x38 x38. Editing this files strings (see screendump above) should present no immediate danger, if I choose to flash it, right? I mean as long as the checksum increments as it does now.
>, but if you have >to ask where to connect, you still have some way to go :-) > > > Stefan
Quite right :-/ but hey - I'm in it for the challenge, and to learn so I'm having great fun already! Thanks all!
steff_dk wrote:
>>Okay, you *may* be lucky and find the strings somewhere > > I am lucky! ;-) > Strings are in this file from the firmware (on the cd for flashing): > www.iamsteff.com/storage/VMEG0411.DNL
Ha, beginners :-)
> It's a straight forward file as I see it in winhex: > www.iamsteff.com/storage/winhex_scr_dump.gif > > First 32 bytes are excluded from the checksummed data - the the first > checksum 4 bytes: x00 x60 x00 x38 then 56 bytes of data and then next > checksum incremented to: x00 x60 x38 x38.
I would interpret these as some kind of address/length pairs, not checksums. But I have looked just a minute.
> Editing this files strings (see screendump above) should present no > immediate danger, if I choose to flash it, right? I mean as long as the > checksum increments as it does now.
I'd probably give it a try (hey, I happily did that with DOS programs years ago, but there I could easily keep a backup copy). If it accepts the patched firmware and doesn't fail another hidden checksum check, why not. That aside, the reason why our bootloader tries to reject patched firmware is simply that we don't want returns from people who edited it, did something wrong, and made their device nonfunctional. Hence, if you break your device, you got a problem.
> Quite right :-/ but hey - I'm in it for the challenge, and to learn so I'm > having great fun already!
If you really want to connect with a debugger, locate the main controller, get the data sheet and look where its JTAG/ISP pins are. Nothing magic behind that. But they probably will not offer you a ready-made socket for your JTAG plug. Stefan
Frank-Christian wrote:
>Wrong. It's a NEC controller: UPD70F3079AYGC >And yes, the controller does have In-System Programming capabilities. >There might be lock bits for ip protection, however. > >You'll need the special NEC development tools for that. > >Mit freundlichen Gr?> >Frank-Christian Kr?>
Ooh - I thought the big gray one was the microcontroller :o) I gues that's some sort of off-chip memory instead. Then I'm dealing with a NEC V850 ... Why does it have to be special NEC dev tools? Cant a generic JTAG debugger get the code, and then I can just disassemble it in IDA Pro 5.0? Stefan wrote:
>Ha, beginners :-)
I know - I hate them too :-))))
>That aside, the reason why our bootloader tries to reject patched >firmware is simply that we don't want returns from people who edited it, >did something wrong, and made their device nonfunctional. Hence, if you >break your device, you got a problem.
That's my main worry - the device costs about EUR 1,000.00 used, so naturally I don't want to break it :-) and that's why I thought on-chip-debugging was better that hacking the firmware cd and see if it accepted that.
>If you really want to connect with a debugger, locate the main >controller, get the data sheet and look where its JTAG/ISP pins are. >Nothing magic behind that. But they probably will not offer you a >ready-made socket for your JTAG plug. > > Stefan
From the link Frank-Christian provided I may alrady have that. But that would mean taking the microcontroller off the board => risky operation isn't it? I'm pretty sure that soldering it back on with my skills will involve bridging at least 2-3 pins at a time ...
http://www.necel.com/en/faq/mi_com/__com_writ.html says:
The contents written to the internal flash memory with a programmer cannot
be read.
This is in order to protect the written program.
If it is absolutely necessary to read the program, consult your authorized
NEC Electronics distributor.
In some cases, it may be possible to take the device to NEC Electronics
and have its contents read. 

Bastards! :-D
Okay - disassembling the firmware it is :-/