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)
Yes. Choose ISP -> Go... and enter a starting address in the RAM address range.
Andy
Andy
How do you upload code to internal ram on the LPC2xxx series of micros?
Regards
Generate a hex file containing code in the RAM address space.
Andy
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
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
Quote from: Andy Ayre on April 25, 2008, 10:16:48 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.
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?)
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
Quote from: 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.
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 :(
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
Quote from: Andy Ayre on April 29, 2008, 03:11:01 PM
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?
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
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
"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?
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)
}
}
Did this thread die? *sniff* Drats... I thought we were so close to getting a working RAM download FM ... *pout*
We will try to reproduce this here and fix any problems that we run into to get it working.
Andy
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
"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.)
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
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)
Quote from: Andy Ayre on May 07, 2008, 03:40:09 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...)
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
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
Please try version 4.22 and let us know if you spot any problems.
Andy
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.
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:
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
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.
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
Hi Andy,
in one of your previous posts you suggested:
Quote from: 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.
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
Added in version 4.32, which will be available by tomorrow morning.
Andy
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:
// 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:
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
We found an issue with this. Please try version 5.44.
Andy
Quote from: Andy Ayre on December 08, 2009, 10:00:33 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
Please try version 5.45. It works here.
Andy
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
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
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):
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
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...
This is the explanation I needed. Thank you.
Nice Christmas
Achim