LPC11U67 - ISP Serial

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPC11U67 - ISP Serial

3,496 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mbehlau on Wed Sep 17 09:05:17 MST 2014
Hi,

i wan't to flash my LPC11U67 about the serial interface. I tested the connection with the flash magic tool with a windows based PC. This is working fine.

Next, i want to flash the device from my linux pc. Unfortunately there is no application, which is supporting the LPC11U67. I tried to add the support, but this won't work.

I tried the mxli software:

sudo ./mxli -N LPC11U67 -F4kix24,32kix1 -B1024,4096 -A0x00000000 -M16ki@0x10000000,2ki@0x20000000 -I0xA0000BC88 -S8@7 -R0x200@0x10000000 -g lpc11U67.hex


If i don't use sudo, i get a memory access error. The process is very fast, but the device isn't programmed. I tested a lpc1769, which is supported directly, and get the same result. (memory access error, and the device isn't programmed).

Then i tested the lpctools. I added the following entry to the "lpctools_parts.def"-file.

0x0000BC88, LPC11U67,           0x00000000, 0x20000, 8,    0x04,    0x10000000, 0x4000, 0x800, 0x800,   1


My command:

./lpcprog -d /dev/ttyUSB0 -c flash ../lpc21isp_197/lpc11U67.hex


Application Output:

Part ID 0x0000bc88 found on line 24
Flash now all blank.
Checksum check OK
Flash size : 131072, trying to flash 11 blocks of 1024 bytes : 11264
Writing started, 11 blocks of 1024 bytes ...
Received error code '9': SECTOR_NOT_PREPARED_FOR_WRITE_OPERATION
Unable to copy data to flash for block 4 (block size: 1024)


Then I tried to add the support to the lpc21isp application in different files. But the output is only:

lpc21isp version 1.97
File lpc11U67.hex:
        loaded...
        converted to binary format...
        image size : 3912
Image size : 3912
Synchronizing (ESC to abort)..... OK
Read bootcode version: 1
13
Read part ID: LPC11U67, 128 kiB FLASH / 20 kiB SRAM (0x0000BC88)
Will start programming at Sector 1 if possible, and conclude with Sector 0 to ensure that checksum is written last.
Erasing sector 0 first, to invalidate checksum. OK 
Sector 0: ..Wrong answer on Prepare-Command (2) (Sector 0)
ErrorString:


Is there another tool, which supported the device directly? Or could somebody check my configs?

Thanks in Adance,

Marcel
Labels (1)
0 Kudos
Reply
8 Replies

3,131 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mbehlau on Fri Jul 17 04:08:16 MST 2015
Hi,

Marc thanks for your help. I changed my command to:

./mxli -N LPC11U68 -F4kix24,32kix1 -B1024,4096 -A0x0000_0000 -M16ki@0x1000_0000 -I0xA0000_7C00 -R0x25C@0x1000_0000,-288@0x1000_0000 -S8@7 -yZ -g blinky.bin


There must be an error in command line parsing, so i must change the "-0x120" to "-288".

ERROR: invalid option/parameter: "-R0x25C@0x1000_0000,-0x120@0x1000_0000


Additionally i have to use a binary-file, instead of hex. If i use a hex-file, a memory access violation occurs.


@capiman

I captured the communication with my logic analyzer (SalaeLogic). You will find the files attached to this post.

http://img5.fotos-hochladen.net/uploads/lpc1n82jx5uzwk.png
http://img5.fotos-hochladen.net/uploads/lpc2cx3osm092r.png

I'm using ArchLinux (4.0.7-2-ARCH #1 SMP PREEMPT Tue Jun 30 07:50:21 UTC 2015 x86_64 GNU/Linux) and a USB<>Serial converter from FutureTechnology (ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) )

Best regards

Marcel
0 Kudos
Reply

3,131 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Andy ESAcademy on Fri Oct 24 01:34:22 MST 2014
Have you tried running Flash Magic under WINE? We don't support it that way for Linux but it does work for Mac OS X.

Andy
0 Kudos
Reply

3,131 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by MarcVonWindscooting on Thu Oct 23 03:01:07 MST 2014

Quote: MarcVonWindscooting
@capiman:Many thanks for pointing me to this thread!
....assume the worst:
Only the 0x1000_0000 .. 0x1000_4000 (16k region is usable)
-M4ki@0x1000_0000
and subtract ISP demands from bottom and top:
-R 0x25C@0x1000_0000,-0x120@0x1000_0000


Sorry for quoting myself: of course i meant:
-M[color=#f30]16ki[/color]@0x1000_0000

@TheFallGuy: thanks for being so clear about not using sudo in that way. I should include some code into mxli to
ask the user why (the hell) he's doing that  :bigsmile: 
0 Kudos
Reply

3,131 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by TheFallGuy on Mon Oct 20 11:53:49 MST 2014
You should NEVER sudo an application like this. What you need to do is make sure the device is accessible by the user. You do this by creating a udev rule. Use your favorite search engine to search for udev rules.
0 Kudos
Reply

3,131 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by MarcVonWindscooting on Mon Oct 20 09:24:54 MST 2014
@capiman:Many thanks for pointing me to this thread!

From my experience with mxli: you need the sudo, probably, because as a normal user, you're not allowed to access /dev/ttyUSB0 (owner: root, group: uucp on my machine, for example). So I suggest adding your regular user to the group 'uucp' or whatever group /dev/ttyUSB0 is
assigned to.

About LPC11U67. User manual states the following:

ISP handler uses RAM 0x1000_017C .. 0x1000_025B
That means: 0x200 bytes are NOT sufficient. mxli will overwrite the ISP area => crash!
Use 0x25C bytes at least (round to a word boundary - which is already the case)

Likewise: the flash commands use the top 32 bytes of RAM and a stack of up to 256 bytes is used from that point downwards.
No comes the question: what the hell is the top of RAM? 0x1000_0000 + 16ki -1 ? 0x2000_0000 +2ki -1 ? 0x2000_4000 +2ki -1 ?
If in doubt (I am in doubt) don't tell mxli about the additional RAM regions and assume the worst:
Only the 0x1000_0000 .. 0x1000_4000 (16k region is usable)
-M4ki@0x1000_0000
and subtract ISP demands from bottom and top:
-R 0x25C@0x1000_0000,-0x120@0x1000_0000

Hope this helps.
Sorry for LPC17 failing, this is a bug of my 3.0 release, because I included bad data into the compiled-in table. 3.1 catches this kind of problem in device information.
0 Kudos
Reply

3,131 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by capiman on Sat Sep 20 10:17:23 MST 2014
Hi Marcel,

just a first observation (I have not yet a LPC11U67 here to retest):

Sending 'P 0 0(0D)(0A)'
Read(Length=6): 'P 0 0(0D)'
Read(Length=3): '0(0D)(0A)'
Answer(Length=9): 'P 0 0(0D)0(0D)(0A)'

Then later:

Sending 'P 1 1(0D)(0A)'
Read(Length=6): 'P 1 1(0D)'
Read(Length=1): '(0A)'
Read(Length=0): ''
Answer(Length=7): 'P 1 1(0D)(0A)'
Wrong answer on Prepare-Command (2) (Sector 1)

In the first case there is the echo of the sent command followed by a "0".
In the second case there is just no "0".

I must check the manual, but I don't think this is a valid case.
But it could also be that communication, reception of characters, or something else is wrong.

Do you have any possibility to record communication when FlashMagic is used?
E.g. portmon on an old (non-64-bit) Windows system. Or a logic analyzer to capture serial traffic?

I assume you use Linux? Which Linux/version? x86 hardware or something else?
Which USB <-> serial port adapter (like FTDI, SILABS, Prolific or something else) or built in COM port?

Best regards,

Martin
0 Kudos
Reply

3,131 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mbehlau on Thu Sep 18 01:29:57 MST 2014
Hi Martin,

you will find the files attached to this post. Additional i uploaded my modified lpc21isp source documents.

The program is just a simple blink light, no special starting address required.

Thanks in advance,

Marcel
0 Kudos
Reply

3,131 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by capiman on Wed Sep 17 11:18:22 MST 2014
Hi Marcel,

can you call lpc21isp again and create a logfile (add "-debug5" to command line)?
The first lines are not relevant, it is conversion hex to bin, you can ignore.
More interesting are the last lines, perhaps from reading part id to the end.

Can you perhaps also upload your hexfile and *.ld file (if you have this).
Does your program start at address 0 or do you try to load something into RAM?

Best regards,

Martin

0 Kudos
Reply