Messages

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

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?

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

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.

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)