upload to RAM *and run*

[Paul Claessen]

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)
  }
}

[Paul Claessen]

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

[Andy Ayre]

We will try to reproduce this here and fix any problems that we run into to get it working.

Andy

[Andy Ayre]

It works if you are not using DTR/RTS to control the device.

Flash Magic is designed so that it does not hold the COM port open, so after sending ISP commands the COM port is closed. Unfortunately when a COM port is closed, Windows (i.e. not FM) changes the signal levels on DTR and RTS. This will disturb the execution from RAM.

The only option I can see right now is to hold the COM port open, which is not ideal because the code is not structured to make it easy to implement.

Andy

[Paul Claessen]

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

[Andy Ayre]

Wow... I didn't say it wouldn't be fixed. Where did you get that idea from? I guess you misunderstood my post.

Do you throw the JFK quote at every company that doesn't fix problems within a few days of you reporting them? That must cause you a lot of frustration. Or perhaps you prefer the companies that don't tell you anything when you report a problem?

Andy

[Paul Claessen]

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?   

[wouter]

Flash Magic is designed so that it does not hold the COM port open, so after sending ISP commands the COM port is closed. Unfortunately when a COM port is closed, Windows (i.e. not FM) changes the signal levels on DTR and RTS. This will disturb the execution from RAM.

So essentially you get a reset immediately after the 'go' because you release the port and windows sets the DTR/RTS back to the defaults? A pity, I hoped to use the command line version for an automated load-and-run (so DTR/DTS control of reset and mode are needed), but if this is correct that can't work. Or can the windows defaults for DTR/RTS be changed (probably wrong forum to ask...)

[Andy Ayre]

How about implementing a user configurable delay along with the Go operation? The delay is the length of time to wait after sending the command before the COM port is closed.

For example specifying 10 seconds will send the Go command and then wait 10 seconds before closing the COM port, which will stop execution from RAM.

Andy

[Paul Claessen]

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

[Andy Ayre]

Please try version 4.22 and let us know if you spot any problems.

Andy

[Paul Claessen]

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.

[Andy Ayre]

It works for me. I have a small test program that toggles pins P0.16 - P0.19. My test involves a Keil MCB2100 v2 board populated with a LPC2129, a Dell Latitude C640 laptop and Windows XP SP2. The Hex file uses locations 0x40000000 -> 0x40000078 and 0x40000200 -> 0x40001400. The board jumpers are configured to use DTR and RTS to control the reset pin and P0.14 (for ISP entry).

Initially all LEDs are solidly on when the board is powered up.
In FM I read the device signature.
I then program the hex file -> no errors.
Next I send the GO command, starting address 0x40000200, ARM mode. The four LEDs dim and visibly flicker.
I close FM and the LEDs continue to flicker.

Next I start FM and the LEDs are continuing to flicker.
Finally I read the device signature and all LEDs are now solidly on. No errors reading the signature.

I then repeated the test on the command line with the following settings:

Code Select Expand

DEVICE(LPC2129,12)
COM(1,19200) HARDWARE(BOOTEXEC, 50, 100)
ERASE(DEVICE,PROTECTISP)
HEXFILE(mini_demo.hex,NOCHECKSUMS,NOFILL,PROTECTISP)
EXECUTE(0x40000200,ARM)


Again, once FM had finished executing the four LEDs had dimmed and were flickering.

Not sure why this isn't working for you.

Andy

[Paul Claessen]

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.

[Andy Ayre]

I have noticed that if I attempt to program the first 120H locations in RAM, the program executes but displaying the contents of RAM in Flash Magic shows that section of memory to be blank. Not sure why this is, but as I mentioned before, it is better to avoid using the first 200H bytes of RAM.

Version 4.23 fixes the verify problem.

Andy