Flash Magic Forum

In-System Programming Support => LPC2xxx => Topic started by: wouter on April 24, 2008, 02:02:12 pm

Title: upload to RAM *and run*
Post by: wouter on April 24, 2008, 02:02:12 pm
When I select LPC2106 (and AFAIK any other LPC) the Execute checkbox is grayed out, so I can't run my uploaded code. Why? The Philips Flash utility could do this. But it requires a few button presses, and has no documented command line interface. Can FM upload to RAM and run? (preferrably with handshake control of reset and P0.14)
Title: Re: upload to RAM *and run*
Post by: Andy Ayre on April 25, 2008, 10:16:48 am
Yes. Choose ISP -> Go... and enter a starting address in the RAM address range.

Andy
Title: Re: upload to RAM *and run*
Post by: pflancer on April 28, 2008, 07:28:05 am
Andy

How do you upload code to internal ram on the LPC2xxx series of micros?

Regards
Title: Re: upload to RAM *and run*
Post by: Andy Ayre on April 28, 2008, 08:44:51 am
Generate a hex file containing code in the RAM address space.

Andy
Title: Re: upload to RAM *and run*
Post by: pflancer on April 28, 2008, 08:57:31 am
Thanks, however the problem I have is with the FlashMagic Tool in that I dont see the option to upload to RAM (using the LPC2468), this was available in the Philips flash programmer. Could you point me in the right direction

Regards
Title: Re: upload to RAM *and run*
Post by: Andy Ayre on April 28, 2008, 09:07:19 am
Set up your linker to locate code in the RAM address space.
Generate the hex file.
Program the hex file.
Use the "Go" option to execute from RAM.

Andy
Title: Re: upload to RAM *and run*
Post by: wouter on April 29, 2008, 08:44:53 am
Yes. Choose ISP -> Go... and enter a starting address in the RAM address range.

First the nitpicking: why is this hidden under a menu item, when a suitable checkbox is available on the main screen?

Second: sadly, it does not work. I have a .hex file that runs OK when uploaded with Insight/Wiggler, but not with FM. I did try it with the Philips Flash utility (I hope I did not make any changed after that) and that *did* work. I see no option to attach a file, but I could cut-n-paste the .hex if that is OK? First part of the .hex (in a dump format) is shown below, I think I correctly skipped the area that should be left to the bootloader.

40000000: 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5
40000010: 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5
40000020: F0 03 00 40 00 03 00 40 08 03 00 40 10 03 00 40
40000030: 18 03 00 40 20 03 00 40 28 03 00 40 30 03 00 40
40000300: 01 00 A0 E3 18 00 00 EA 02 00 A0 E3 16 00 00 EA
40000310: 03 00 A0 E3 14 00 00 EA 04 00 A0 E3 12 00 00 EA

Third: when I enable verification, FM hangs.
Title: Re: upload to RAM *and run*
Post by: Paul Claessen on April 29, 2008, 02:32:08 pm
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?)
Title: Re: upload to RAM *and run*
Post by: Andy Ayre on April 29, 2008, 02:35:32 pm
We will double-check this but the first 512 bytes of RAM are used by the bootloader, so they cannot be used by any application. Therefore Flash Magic does not program those locations. This is documented in the LPC2xxx user manual.

Andy
Title: Re: upload to RAM *and run*
Post by: wouter on April 29, 2008, 03:06:45 pm
We will double-check this but the first 512 bytes of RAM are used by the bootloader, so they cannot be used by any application. Therefore Flash Magic does not program those locations. This is documented in the LPC2xxx user manual.

The first 512??? Quoting from http://www.nxp.com/#/pip/pip=[pip=LPC2104_2105_2106_6]|pp=[v=d,t=pip,i=LPC2104_2105_2106_6,fi=45994,ps=0][0]
p 180:

RAM used by ISP command handler
ISP commands use on-chip RAM from 0x4000 0120 to 0x4000 01FF. The user could use this area, but the contents may be lost
upon reset. Flash programming commands use the top 32 bytes of on-chip RAM. The stack is located at RAM top - 32. The
maximum stack usage is 256 bytes and it grows downwards.

So the first 0x120 are definitely free for the application! I put a copy of the bootvectors there, if FM does not write that (without any warning!) I can understand why my code does not run :(
Title: Re: upload to RAM *and run*
Post by: Andy Ayre on April 29, 2008, 03:11:01 pm
Locations 40000040H to 4000011FH are used by the RealMonitor. Flash Magic doesn't know if this to be used or not. The fact that NXP chose to make the RealMonitor and bootloader RAM usage non-overlapping indicates that it is possible for both to be used. In addition, Flash Magic is optimized to program in 512 byte chunks.

My general recommendation is to avoid this area.

Andy
Title: Re: upload to RAM *and run*
Post by: wouter on April 30, 2008, 12:58:19 am
Locations 40000040H to 4000011FH are used by the RealMonitor.

I agree that it makes sense to protect the areas used by the bootloader, but I don't know what the RealMonitor is, and I don't use it, so I would expect that RAM to be useable. At the very least the vector block (or whatever it is called) should be available! And: maybe give some error message when the .hex contains addresses that will not be written?
Title: Re: upload to RAM *and run*
Post by: Paul Claessen on April 30, 2008, 07:22:35 am
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
Title: Re: upload to RAM *and run*
Post by: Andy Ayre on April 30, 2008, 09:10:01 am
If FM writes over the bootloader RAM and the bootloader fails, it will stop communicating with FM. This will generate an error message in FM and then people would contact us... Likewise if they are using the RealMonitor and they are using FM, and all of a sudden the RealMonitor stops working, it will be us that is blamed.

It is assumed that the user has read the datasheet/user manual and knows what they can and can't do with the device.

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

Andy
Title: Re: upload to RAM *and run*
Post by: Paul Claessen on May 01, 2008, 07:09:18 am
"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?
Title: Re: upload to RAM *and run*
Post by: Paul Claessen on May 01, 2008, 07:36:48 am
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)
  }
}

Title: Re: upload to RAM *and run*
Post by: Paul Claessen on May 06, 2008, 06:43:30 am
Did this thread die? *sniff* Drats... I thought we were so close to getting a working RAM download FM ... *pout*
Title: Re: upload to RAM *and run*
Post by: Andy Ayre on May 07, 2008, 09:48:37 am
We will try to reproduce this here and fix any problems that we run into to get it working.

Andy
Title: Re: upload to RAM *and run*
Post by: Andy Ayre on May 07, 2008, 03:40:09 pm
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
Title: Re: upload to RAM *and run*
Post by: Paul Claessen on May 08, 2008, 08:02:32 am
"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.)
Title: Re: upload to RAM *and run*
Post by: Andy Ayre on May 08, 2008, 09:07:53 am
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
Title: Re: upload to RAM *and run*
Post by: Paul Claessen on May 08, 2008, 11:12:10 am
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 ..  ;D .. 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?   8)

Title: Re: upload to RAM *and run*
Post by: wouter on May 08, 2008, 02:37:55 pm
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...)
Title: Re: upload to RAM *and run*
Post by: Andy Ayre on May 09, 2008, 10:35:59 am
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
Title: Re: upload to RAM *and run*
Post by: Paul Claessen on May 09, 2008, 11:21:54 am
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


Title: Re: upload to RAM *and run*
Post by: Andy Ayre on May 12, 2008, 11:48:42 am
Please try version 4.22 and let us know if you spot any problems.

Andy
Title: Re: upload to RAM *and run*
Post by: Paul Claessen on May 13, 2008, 08:31:55 am
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.
Title: Re: upload to RAM *and run*
Post by: Andy Ayre on May 13, 2008, 09:38:41 am
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]
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
Title: Re: upload to RAM *and run*
Post by: Paul Claessen on May 13, 2008, 10:08:51 am
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.
Title: Re: upload to RAM *and run*
Post by: Andy Ayre on May 13, 2008, 02:36:23 pm
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
Title: Re: upload to RAM *and run*
Post by: Rolf Meeser on September 04, 2008, 02:45:06 am
Hi Andy,

in one of your previous posts you suggested:

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.

Have you implemented this function? It would save my day!

My problem is, that the "OS" (Windows XP) asserts RTS and DTR once FM closes the COM port. It also sends a break!

1.
Assertion of the handshake lines immediately resets the device, hence the program in RAM, which has just been started with the EXECUTE command, comes to a sudden death...

2.
Not using hardware handshaking to control DTR/RTS in FM is no option, because of the break being sent by Windows:
Assume you put the board into ISP mode manually, before you start FM. The LPC sees the break on its RXD0 line, and interprets this as the start bit of the "?" character used for auto-bauding! This results in the auto-bauding to calculate a wrong baud rate.

3.
The default COM port state (when no application is using it) seems to be related to a weird Plug&Play feature for serial ports. Not sure why this is still used, since serial mice are rather old-fashioned these days...
Anyway, I didn't find a way to disable it.



Since I need the program in RAM to run for a short time only, a configurable delay would be extremely helpful!

Rolf

Title: Re: upload to RAM *and run*
Post by: Andy Ayre on October 16, 2008, 03:44:53 pm
Added in version 4.32, which will be available by tomorrow morning.

Andy
Title: Re: upload to RAM and run *in ARM mode*
Post by: achim on December 08, 2009, 09:03:37 am
Salut, ladies and gents,

I have just started programming with the Production System, and I have the same problem as the users above: A program loaded into RAM does not start there.

My code:

Code: [Select]
// fm_connect, fm_program etc. runs fine.

presults = fm_select_debug_mode (FM_DEBUG_MODE_ON, "f:\\kram\\reset2.fmd");
presults = fm_reset (FM_RESET, 0x40000200, (1000 << 16)); // specify ARM mode and 1 second delay

I want the target to run in ARM mode but FM invokes a "Thumb" reset:

Code: [Select]
tx> U 23130\d\a
rx> U 23130\d\a
rx> 0\d\a
tx> G 1073742336 T\d\a
rx> G 1073742336 T\d\a
debug> COM Port RX flushed

Please help me out. What can I do to make the processor run in ARM mode?

My FlashMagic version is 5.43.1827.

Regards,
Achim
Title: Re: upload to RAM *and run*
Post by: Andy Ayre on December 08, 2009, 10:00:33 am
We found an issue with this. Please try version 5.44.

Andy
Title: Re: upload to RAM *and run*
Post by: achim on December 09, 2009, 01:26:36 am
We found an issue with this. Please try version 5.44.
I did. Same behaviour, same debug output. Problem is NOT solved.

The fm_version() I can see 2.15.1834, is that correct?

Achim
Title: Re: upload to RAM *and run*
Post by: Andy Ayre on December 09, 2009, 10:45:19 am
Please try version 5.45. It works here.

Andy
Title: Re: upload to RAM *and run*
Post by: achim on December 10, 2009, 02:00:53 am

OK, I did it and it works fine. The microcontroller jumps into the RAM routine and runs it. Thank you!  :)

One more question: Are you no longer closing the COM port (as described in the manual)? My device is not reset after the delay elapses, and I read from this thread that a device reset should be a side effect of Windows closing the COM port - or did I get that wrong?

I'm not complaining about that - I prefer having full control over the reset wire, so it's even better this way. I'd just like to know.

Regards,
Achim
Title: Re: upload to RAM *and run*
Post by: Andy Ayre on December 10, 2009, 08:10:18 am
The COM port is always closed. Try connecting to it using Hyperterminal immediately after using Flash Magic, and it will work because the COM port is not in use.

Unless you check/tick the option "Use DTR and RTS..." in the advanced options, closing the COM port won't have any effect on the device. However if you do enable the DTR/RTS option then these signals will attempt to control RST and the ISP entry pin to reset the device just before closing the COM port. However you need to support this in your hardware.

Andy
Title: Re: upload to RAM *and run*
Post by: achim on December 11, 2009, 12:32:40 am
Sorry for annoying you, Andy, but this does not answer my question.

I'm not using the FM user interface or Hyperterm or anything like that, I'm using the flashmagicarm.dll in my own program and nothing else. It looks like this (stripped to the essence):

Code: [Select]
 options.hwconfig       = FM_HWBOOTEXEC;
 
  presults = fm_connect(&options, sizeof(options));

  presults = fm_program ( .... ); // load LPC application to RAM

  presults = fm_reset (FM_RESET, 0x40000200, (1000 << 16)); // run application after 1 second delay

  // application takes control over the LPC

  // talk to the app using fm_raw_transmit and fm_raw_receive

The LPC hardware is not reset during all this although it takes much more than the second mentioned above.

That's not a problem, I need it exactly this way. But I'm confused because the DLL manual (ch. 4.17 - fm_reset) says something different - or I read it wrong. This is important to me because I'm developing a long-term service application and I must know whether or not I can rely on the behavior I see.

I hope you can explain. Have a nice weekend

Achim


Title: Re: upload to RAM *and run*
Post by: Andy Ayre on December 11, 2009, 07:34:18 am
You have three options:

Use options.hwconfig = FM_HWBOOTEXEC; and do nothing else. When the COM port is closed DTR/RTS will be used to reset your device so it executes your firmware. This assumes you have connected DTR/RTS to the RST and ISP entry pins. You don't need fm_reset in that situation. However the contents of RAM are cleared on reset, so your RAM-based code won't be executed.

Or you can send fm_reset(FM_EXECUTE...) to start executing from RAM or flash. When the COM port is closed DTR/RTS are not used and the device should continue to execute code. This is not a device reset however, and the contents of RAM will not be cleared.

The other option would be to use fm_reset(FM_EXECUTE, 0x00000000, ...). This would start flash-based firmware executing without a device reset.

So, you need to choose - use fm_reset or DTR/RTS and execute from flash or RAM. Then pick the correct combination. If you are using DTR/RTS and the device is not resetting and executing from flash then: check the RST and ISP entry pins with a scope to ensure that DTR/RTS are controlling them. And also note that the device will execute the bootloader anyway if the flash does not have the correct checksum at location 0x00000014.

The difference between FM_RESET and FM_EXECUTE when passed to fm_reset is that FM_EXECUTE ensures that DTR/RTS are not used when the COM port is closed, regardless of the configuration settings.

So to summarize, in your example I would expect your device to be reset when the COM port is closed, providing you are actually using DTR/RTS in hardware, the checksum at 0x00000014 is correct, etc.

Andy

Note: I mentioned Hyperterminal as a quick test to prove Flash Magic is closing the COM port, nothing else...
Title: Re: upload to RAM *and run*
Post by: achim on December 17, 2009, 11:43:24 pm

This is the explanation I needed. Thank you.

Nice Christmas

Achim