Embedded ISP Programming

[phil rescenzo]

Hello

I am working with the 932 in an embedded USB device. The USB Peripheral also has an 8051 attached, through which I am turning on ISP mode and reading / writing security registers.

I have a Windows app that runs the whole show, downloading firmware to the Cypress USB chip and , through that chip, attempting to upgrade the LPC932A1.

I am monitoring the SERIAL OUT of the 932 both IN windows and with a serial com app.

I had to sort of suss out exactly how the 932 r3esponds to INTEL HEX records and I think , for the most part, I have that part working. I can see that the 932 responds with the proper '.' character now for every Hex Record I send, either requesting data, erasing sectors or writing registers or hex code ..

I am able to erase the proper sectors. And yes, the very first thing I did once I tested the code was to protect all of sector 7 with bit 2.

Now, when I send the actual HEX file down there I get the '.' ACK response fromt he device for every line, Then I send the RESET record at the end. I never send the last EOF Hex record because, it appears that the firmware remapped that HEX record type (0x01).  Of course, there is no reason to send the EOF when you think about it.


This all appears to go ok but when I test the  CRC of the new burn in FlashMagic it shows that they do not match with the file's CRC. But when I burn the file from FLash Magic the code works. Same Hex file.

I am wondering why the LPC would respond with the '.'  when it is apparently not  writing corrrect data..

Are there some other things I am missing here?  

I am not setting or changing any other registers during this process.

Thanks

Phil



Any info appreciated.

[phil rescenzo]

Also, I noticed that the keil Compiler places this line as the first in the hex file:

:0CFF000063001E01000000000000000073


is 0xFF00 the proper place for this for the 932A1?


just searching in the dark...

[Andy Ayre]

Are you remembering to split hex records when they cross page boundaries?

The record at FF00H is supposed to program some bits in UCFG1, however Keil changed their startup file later on to locate these bytes at FFF0H. Flash Magic therefore ignores records at FF00H and uses records located at FFF0H to program UCFG1. You can download a new start900.a51 from keil.com.

[phil rescenzo]

Yes Andy!

I ended up decomposing the hex file in memory and generating another intel hex image which had 64 byte data segments.  Works well..  Once I thought about it became embarassingly clear.

I am curious about some of the single character responses I see from the LPC but.. I will eventually figure those out. At least I now have that processor upgradable via USB.

I see the latest start900.a51. Hmmm.. some minor changes in there.. I don't understand what's with the memory at FFF0 though. I have to go read about that.. and why keil can use it.

Thanks again.

P

[Andy Ayre]

There is no memory at FFF0H. The tool that is processing the hex file must take this record and program the UCFG1 accordingly. Flash Magic does not support all the bytes in this record to stop people getting stuck in a situation where they cannot reprogram their device.

This is an optional feature that users can take advantage of to specify the device configuration at the same time as the application.

[phil rescenzo]

Ahh.. very welcome and important info..  news  I was just trying to figure that out! That explains whey the 932 memory map stops at FFEF.  Doh!

Thanks again Andy.   I hope I can help you someday.

Phil