upload to RAM *and run*

wouter · 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)

Andy Ayre · April 25, 2008, 10:16:48 AM

Yes. Choose ISP -> Go... and enter a starting address in the RAM address range.

Andy

pflancer · April 28, 2008, 07:28:05 AM

Andy

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

Regards

Andy Ayre · April 28, 2008, 08:44:51 AM

Generate a hex file containing code in the RAM address space.

Andy

pflancer · 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

Andy Ayre · 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

wouter · April 29, 2008, 08:44:53 AM

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.

Paul Claessen · 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?)

Andy Ayre · 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

wouter · April 29, 2008, 03:06:45 PM

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]

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

Andy Ayre · 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

wouter · April 30, 2008, 12:58:19 AM

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?

Paul Claessen · 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

Andy Ayre · 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

Paul Claessen · 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?