Messages

I'm beginning to doubt my 2378.
I have an LPC2148 on order, when that comes in I will try it with an 21xx.

By the way, when I check the verify box, FM 4.22 will crash, as where 4.21 would hang.

Unfortunately, I still can't get it to work.
I SEE that the reset (DTR/RTS) at the END of the GO cmd no longer occurs, but still: no go...

What I did try, is load the program (and execute) through JTAG, and then use the GO cmd in FM.
What I saw (only once) was that the leds suddenly started to blink much faster.
I can explain that by assuming my initial program ran after reset, on the 4Mhz internal RC clock, but after the GO cmd, ISP probably set up a higher clock frequency.
However, as said, I only could do this once. ALL (MANY!) other attempts to do this resulted in autobaud failure. In most cases a simple reset wouldn't fix this: had to power cycle the board.
I'm beginning to suspect the 2378's ISP mode... after I download (FM) the image, I break in using JTAG, and notices that nothing got loaded at the RAM locations (even though the whole ISP dialog looked good on my serial port sniffer) and the system would be spinning in an abort exception. Afer a GO it would spin in a different location, but still in flash.
I think I'm going to give up on this...

Thanks to FM for their efforts though.

There's still something I don't understand:
And, btw, I don't think its closing the COM port that is the culprit!
Here's my argument (and dilemma):

When FM send its first ISP command, it opens the COM port, raises DTR/RTS to reset the uC and get it in ISP mode.
When done, it DE-assers DTR/RTS!
It then does the autobaud thing and sends the command/data to the uC.
After that, it closes the COM port.

The claim was made above that closing the port would do something nasty to DTR/RTS which will reset the device.
That surprised me, because why would the OS assert Data Terminal Ready (!) and Request To Send (!) when it CLOSES a COM port.
That doesn't make senses, because a closed COM port is NOT ready, and does NOT want to send anything.
So I checked the RS232 signals.
And indeed, absolutely nothing happens to DTR/RTS when you close a COM port!

Then when I issue the GO command, the whole sequence starts all over again.
Realizing I am still in ISP mode BEFORE I do the GO cmd, I disabled the DTR/RTS uage in FM at this point.
However, FM then STILL does the autobaud thing, which of course fails, because that only works aften a proper reset.
So I turned DTR/RTS back on for the GO command.

So, here is what I don't understand:
After my first ISP write, the uC is still in ISP mode.
Then the GO command resets the uC BUT RETURNS TO ISP mode! Unless the autobaud function uses MORE RAM than what is stated in the manual about RAM usage, I don't understand why the GO doesn't work. Yes, we did a reset, but practically stayed in ISP mode. So my RAM code should still be intact.
What am I missing here?

-- 2 minutes later --

After I wrote the above, I thought of something else, had a closer look at the end of the GO command.
Now I DO see a brief assert of DTR/RTS at the END of the GO command! (Didn't see that when the earlier WRITE ended with a port close!)
Clearly, THIS reset is what caused the problem.
A closer look however showed that these signals are briefly asserted ... BEFORE the COM port is closed!
So, it's NOT the OS that's doing something nasty upon a COM port close!
It's FM!
Why does FM do a 'reset' after its GO command (and before closing the port)?
THAT's the problem, I bet... Not the close/OS.

~ Paul

Well, yes, I then probably misunderstood. I guess I, wrongly, interpreted 'is not easy' as 'too difficult, forget it'.
Sorry for jumping to conclusions.
And no, I don't throw these JFK quotes around. You're the first!
Which shows I care about you guys ..  .. hadn't I cared I would simply have moved on.
Furthermore, let me state for the record that I DO appreciate what you guys are doing with FM.
And I AM impressed by your prompt and to-the-point replies.
For that, nothing but kudo's.

I wish a certain software company in Washington state would take your support model as an example (rather than charging me $250 for a telephone call to report to them that the installaion procedure for a legitemately purchased version of Visual Studio 2008 keeps insisting that the entered product key, copied from the CD box, is invalid ... but I digress...)

Now ... is that fix ready yet?   

"the code is not structured to make it easy to implement"

"We choose to go to the moon. We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win..."
- John f. Kennedy

(Could't resist. I know this is free software and therefore to criticize it always sounds a bit ungrateful, but to NOT fix a bug because it's not easy is, IMHO, a bit of a weak excuse)
(Also: while I don't know the structure of the code, I can't see why FM shouldn't simply keep the port open. As for making that change, why is it difficult to open the port at program start, and close it when the program ends, and remove all other instances op port open/close's? Is the code structure so convoluted that that would present a problem? Oh well.. I guess we'll have to live with the fact that FM can't do RAM download/execute's.)

Did this thread die? *sniff* Drats... I thought we were so close to getting a working RAM download FM ... *pout*

Steve,

Intel hex and uuencode is not a 1 to 1 relation: Only the actual 'data' that is to be flashed should be uuencoded. An Intel Hex file contains more than just 'data' that is to be flashed. It also contains location information, start address information, and checksum information. From this, FM generates ASCII commands that do all the erasing, reading and writing.
So, only PARTS of the hex file are being converted to uuencode.
The reason NXP wants uuencoded data is that it is more compact than hex encoded (3 8-bit binary bytes map to 4 ASCII bytes, rather than 6 ASCII bytes in hex).

You're missing nothing!
FM takes as input an Intel Hex file.
It (FM) will then generate the necessary ASCII commands and convert the data to Uuencoded data.

In testing this, I stripped everything down to a 60 byte program (that would blink some LEDS), no interrupts, linked to load at, and execute from 0x4000 0200.
According to the above discussion, this should work.
It worked fine when loaded through JTAG.
It loads fine with Flash Magic (even though it loads TWO 512 byte blocks, even though the image is only 60 bytes!?)
Issueing the Go 0x40000200 A command, however, didn't do anything (it got echoed, so I  guess I AM in ISP).
Then I noticed, when I gave the Go command, an LED would blink (twice) that otherwise only blinks when the board gets reset!
Obviously this reset comes from FM (when I disable use of RTS/DTS just prior to doing the GO, I would get an autobaud failure, indicating that FM indeed started the whole reset-autobaud sequence again -would think a simple state variable "isp-ready" could prevent this-).
Although I don't see how, I'm beginning to suspect this reset to be part of the problem.

Anyway, wouldn't this be simple to reproduce for the FM-guys?

Here's my test program (for an LPC2378, maybe it will run on most LPC2xxx's) (I'm using Keil's µVision to build):

            AREA    RESET, CODE, READONLY
            ARM

mystart   LDR   R3, =0x1FFFF   ; Delay loop count
   MOV   R1, #0xFF   ; Leds
   LDR   R0, =0x3FFFC000   ; FIO2 base
   STR   R1, [R0, #0x40]   ; DIR output

lp0   STR   R1, [R0, #0x5C]   ; CLR

   MOV   R2, R3      ; Delay loop
lp1   SUBS   R2, R2, #1
   BNE   lp1

   STR   R1, [R0, #0x58]   ; SET

   MOV   R2, R3      ; Delay loop
lp2   SUBS   R2, R2, #1
   BNE   lp2

   B   lp0

             END

And the scatter file:

LR_IROM1 0x40000200 0x00005C00  {    ; load region size_region
  ER_IROM1 0x40000200 0x00005C00  {  ; load address = execution address
   *.o (RESET, +First)
  }
}

"We will look into allowing the first 40H bytes of RAM to be programmed by FM"

40H assumes that Realmonitor is used. Many people don't use it, so why not make it a configurable option to either skip the range 0x4000 0120 - 0x4000 01FF, or 0x4000 0040 - 0x4000 01FF. That's also a nice indication for people that some regions in RAM should not be loaded.

How about the 256 + 32 bytes at the top of RAM for stack usage?

Shouldn't it be the responsibility of the firmware image builder (programmer), by using scatter loading, to not load in regions that are used by the boot loader and/or Realmonitor?
I would expect FM to load whatever and whereever I ask it to load. If it then overwrites regions used by the boot loader, it's the programmer's fault, not FM's.

Besides, if FM tries to be smart about these regions, it's not going to help in any way if the programmer didn't know about those regions! (his stuff simply doesn't get loaded right and nothing works).
If, on the other hand, the programmer DOES know about these regions, then FM doesn't HAVE to be smart about them.

And if this all means that FM is slightly less efficient (i.e. no longer optimized for 512K blocks), so be it.

Just my 3 cents (adjusted for inflation).

~ Paul

I'm experiencing exactly the same problems as Wouter, but on a LPC2378 (no execution after a Go 0x4000 0000 after loading a RAM based executable, hang when Verify enabled).
I put a serial port sniffer on it, and noticed that the ISP transfer begins with reading 4 bytes at 0x4000 0200 and then start writing at 0x4000 0200!
NOT at 0x4000 0000.
Note that Flash Magic in File->Information states the Flash Range as 0x40000000 to 0x40000ABB.
What happened to the first 512 byte block?
(And what's being read at 0x4000 0200?)

~ Paul

(As for the serial port sniffer: wasn't there also a (debug?) mode in Flash Magic that dumps the serial port traffic? If so, how do I invoke that?)