Messages

No, I havn't encountered a bug...everything seems to work correctly.  I have built a programmer for our manufacturing department and am trying to emulate the functions of the LPC chips with it so that I can use Flash Magic to write hex files to it.

I want to understand what Flash Magic is doing by sending data that is different than the hex file (for the first 512 bytes at least).  If it is not sending different data, I would like to know how I am misunderstanding this problem.

I am aware of the boot block remap in ISP mode and the visibility of the interrupt vectors starting at location 0.  Does Flash Magic send modified data to manipulate this visibility?

John

First, I'd like to say that Flash Magic is a great piece of software and incredibly usefull.

I am working on a project with the LPC2134 and I have a couple of questions regarding the UUEncoding protocol used by Flash Magic.  When I attempt to decode a line it looks as though the decoded line doesn't match the expected data.

The first 45 bytes of my hex file are:

0228BE7B FE7A0079 00222202 19DC7F00
7E407D01 7C00124C A7BF5503 024CAB12
4CAE2202 2C57D218 7F02124A F1

During a programming operation, Flash Magic sends the following UUEncoded line:

M`BB^>_YZ`'D`(B("&=Q_`'Y`?0'`$B'QI[]5`P),JQ),KB("+%%?2&'\"$DKQ

My first observation is that the length of the line is 62 bytes and LPC datasheets recommend no more than 61 bytes.  Is this correct?

My second observation is that this line decodes into the following 45 bytes:

0228BE7B FE7A0079 00222202 19DC7F00
7E407D01 C01221F1 A7BF5503 024CAB12
4CAE2202 2C515F48 61FC0849 2B

Am I decoding this incorrectly?  Is this the standard decoding scheme?

Any help you could give would be greatly appreciated.

John

Hi Andy,

Thank you very much!  You have helped me immensely.  I tried the new bootloader and it worked perfectly!

Thanks again!

John

Actually, I have tried to use this command and found that it causes the processor to fail!

I loaded the chip with verified executable code and then attempted to use the "Device Configuration" feature on the chip.  After applying power to the chip, my code wasn't running.  I looked at the data stored in flash by using the "Display Flash" feature and noticed that the first two bytes of flash were corrupted.

So the effect of this command seems to be the writing (or overwriting) the first two bytes of flash.

John

Do you know if there will there be some sort of posting or announcement when this feature is either implemented or scrubbed?

John

Hi Andy,

Thank you for your reply.

I have been using the support tools at the NXP website to try to get some documentation on this.  As of right now, I am engaged in a forum-like discussion with one of their engineers.  I don't know if he knows what I am referring to when I ask him to verify the existance of this command record number.

If Flash Magic was written with the intention of allowing this command to be accessed specifically for the 89(L)V51RD2 families, Embedded Systems Academy must know where I can get documentation and/or the bootloader that accepts this command.  I have even downloaded the most recent release of the bootloader that I could find from the NXP site (V05) and it fails to accept this command in the way that I understand it.  In fact, sending this command causes my target system to fail!

Is there any more help you could provide?

John

Hello!

I'm working on a project using the 89V51RD2 chip from Philips.  I noticed that Flash Magic provides an option for this chip called "Device Configuration" under the ISP menu.  It looks like it would allow the chip to enter ISP in several different ways, not just via autobaud detect after reset.

This command is very appealing to me, but I can't get it to work.  I used a port monitor to see that the ISP intel hex record command number was 0x0C.  There is no documentation for this command in the 89V51RD2 datasheet.

Could someone tell me where I can find documentation for this command?

John



Post Edited (11-03-06 14:05)