upload to RAM *and run*

[Rolf Meeser]

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

[Andy Ayre]

Added in version 4.32, which will be available by tomorrow morning.

Andy

[achim]

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 Expand


// 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 Expand


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

[Andy Ayre]

We found an issue with this. Please try version 5.44.

Andy

[achim]

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

[Andy Ayre]

Please try version 5.45. It works here.

Andy

[achim]

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

[Andy Ayre]

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

[achim]

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 Expand


 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

[Andy Ayre]

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

[achim]

This is the explanation I needed. Thank you.

Nice Christmas

Achim