On Sat, 10 Nov 2007 09:59:51 -0600, "steff_dk" <jsteffensen@gmail.com>
wrote:

>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?

You didn't read the documents I've provided the link for.

This controller doesn't have JTAG but a proprietary ISP port, and IDA Pro
won't know the V850 opcodes. This means you MUST have the NEC tools.

>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 ...

ISP means In-System programming, so the controller can remain on the board
provided that the external connections to the ISP pins and to Vpp allow
this.

See document #3 from my link, chapter 17.

Mit freundlichen Gr&#4294967295;&#4294967295;en

Frank-Christian Kr&#4294967295;gel

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 :-/

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 ...

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

>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!

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

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

>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! 

> 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�V as meeting the requirements for safety related systems. 

"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