manual UM10375, aplic. note AN11229 confusing

[lpcware]

Content originally posted in LPCWare by Harrie Nijhof on Mon Sep 15 14:39:21 MST 2014
In AN11229 page 3 is an example of an UUencoded line:  "The line sent to the NXP controller is: #%`^H<CR><LF>". But on page 7 and in the manual is stated
with the write command:    "<number of bytes> is the desired bytes. The number of bytes must be in multiples of 4." This looks like a contradiction.
Next, the minimum number of bytes to be copied to flash is 256: in case of lesser payload, what is the best stuffing, 0's or 0xFF's?

[lpcware]

Content originally posted in LPCWare by Harrie Nijhof on Tue Nov 04 15:21:07 MST 2014
Dear Marc,
Thank you for your answer.
I just succeeded in actually writing some code to an lpc 1343 and reading it back! Found eventually that the mpu answers with a code, 0 and not CMD_SUCCESS.
Escaped neigh the nuthouse.
Leider, no blinking led, but hey, no smoke either.
Harrie

[lpcware]

Content originally posted in LPCWare by MarcVonWindscooting on Fri Oct 31 11:02:40 MST 2014
Hello Harrie,

yes, it's slippery. And once, you've read enough manuals, you can't remember any more what you read in which one and/or which version of it. But I believe I can remember, that echo on/off takes effect AFTER the result code return.

The checksum error you mention is a completely different one from what I understood to be a problem while transferring data.
NXPs ARM7 devices have a 'code validation checksum' in FLASH word #5 while all NXP Cortex-M* have
this stored in FLASH word #7. That's what the comment in the code is about - the difference between Cortex and ARM7. Doing this the wrong way possibly destroys on of the ISR entries - very annoying!

Marc

[lpcware]

Content originally posted in LPCWare by Harrie Nijhof on Wed Oct 29 07:54:19 MST 2014
Marc,
I am not complaining about your program. I am not complaining at all, I merely tried to express how hard it is for a lone bungler like me to get things running. And i am waay behind the boys who are entitled to critisize so(u)rcerers like you.
It is like crossing a river on slippery and wobbling stepstones. You have to learn which ones are save and which ones rock and before you are on the other bank, you are soaking wet. But you made it, or at least you tried.

for instance does "A 0" (is echo off) self issue an echo? Generally, is the echo before or after the result of the command? Or is the echo overwritten by the result?

About the "Checksum Error":  Most likely is this  from the write to ram command, perhaps caused by my equipment. But all signals are clean and square on my Rigol DS 1052. And so I looked in the isp.c source code and found lines 52, 53
* - BIIIIG BUG fix: checksum in vector 5 (reserved), not in vector 7 (FIQ).
* - still not correct (the above!)
That scared me off, I decided to go for the step by step Python aproach. With stunning success, I can startup the communication, can turn echo off and can get the id number, but I never get the expected result on a read command. I never read "CMD_SUCCESS" and yet I get the ID number. (I fear I soon have to vacuum-clean the bitbucket.)

Greetings Harrie

[lpcware]

Content originally posted in LPCWare by MarcVonWindscooting on Mon Oct 27 07:54:13 MST 2014

---

Quote: Harrie Nijhof

Technically everthing works fine, for instance, I can read the chips id with mxli, but writing a small .bin file fails with
"Checksum Error". Helpfull isn't it?
Now i am working on a step by step Python program. Nothing sofisticated, am not even sure I will succseed.

Greetings Harrie

---

What exactly are you complaining about?

My experience with checksum errors is, that they can be caused by mxli overwriting the bootloaders RAM region. What is caused by invalid information about the device (compiled-in table) because I made an error or because it was not/not properly documented at the time of writing mxli. This will most probably be true for all other device programmers.

I don't use LPC13xx so far - no experience with it. Have you tried different speeds? With or without 'echo'? Used full debugging output?
Not all chips have the same power and features. mxli doesn't choose speed / echo based on the device ID. I try to keep it simple. You have to tell mxli.

If men were still men, they would use mxli's option --virgin and supply their own LPC device definition on the command line ;-)

If you find a bug, I'll happily fix it.

[lpcware]

Content originally posted in LPCWare by Harrie Nijhof on Sat Sep 20 04:50:13 MST 2014
@ starblue:
To be honoust, I did try lpc21isp without succsess, but, as I later found, that was totally due to my wacky rs232-ttl converter. That converter is now ok.
For now, I am knocking up a python program and in the process learning a whole lot. Once knowing how things work I think I will revert to a more sofisticated stuff, like the program you advised.
Lovely thing that Olimex 1343 board, don't you think? (Tip, never touch the 5 Volt pin with a 12 Volt lead, then the little square thingy in the middle gets a kind of roof, and that is the end)
Thank you for your reaction, greetings Harrie

[lpcware]

Content originally posted in LPCWare by starblue on Fri Sep 19 00:44:16 MST 2014
Have you tried lpc21isp?  That has always worked for me, including on an Olimex 1343 board.

[lpcware]

Content originally posted in LPCWare by Harrie Nijhof on Thu Sep 18 14:06:19 MST 2014
Hi Vimes,

I did assume that that everything in that app note relates to NXP isp programs. I lot of your remarks confirm what I allready suspected. Thank you.
I am trying to set up an older computer to program a LPC1343. Many of these desktops are "abandoned" because of the expiration of Windows XP.
Ideal to change it into a Linux machine, altough all flasherprograms I tried so far, did fail one way or another. I use only the serial port, the (Olimex) board is simply connected to the
PC via a breadboard. I could buy a complete set, but I want to understand what happens. Technically everthing works fine, for instance, I can read the chips id with mxli, but writing a small .bin file fails with
"Checksum Error". Helpfull isn't it?
Now i am working on a step by step Python program. Nothing sofisticated, am not even sure I will succseed.

Greetings Harrie

[lpcware]

Content originally posted in LPCWare by OldManVimes on Thu Sep 18 07:24:52 MST 2014
Hi Harrie,

I'm not sure I can follow your reasoning. The application note encodes 3 source bytes into 4 UU-encoded bytes. Later it encodes 4 bytes into 8 UU-encoded bytes (by padding the 4 bytes to 6 bytes). So far so good. That example should be taken at face value. It has no relation to a specific NXP device or the constraints imposed by ISP mode commands of such devices. It simply explains the process of UU-encoding a (short) stream of bytes.

If you want to transfer 256 bytes into the RAM of your device (in order to copy it to flash afterwards), you setup a write of exactly 256 bytes. Because of UU-encoding you end up sending data for 258 bytes, where the last 2 bytes are padding for the UU-encoding. Now, what does the CPU do with those 2 extra bytes? We simply do not know with 100% certainty. In a reasonable world, it discards them because we only wanted to write 256 bytes. It is fair to assume that this is the case. A very bad implementation would actually write them to RAM, although the chances that we would be affected by that are low.

The specification is clear about the checksum. It does not include the padding. The checksum is simply the sum of the 256 bytes. So again, what happens when the ISP code is of bad quality and it somehow includes the padding in the checksum? Well that does not have to be a problem if the value of the padding is zero. In that case, the checksum is not affected. So the prudent thing to do is to pad a UU-encoding input frame of 3 bytes with zeros since that allows the ISP implementation to be really bad without causing big problems.

The page stuffing you mention can make sense, but you should then add those bytes with the 0xff value to the regular data to send. It has no relation to the padding related to UU-encoding. So if your source data ends in a block of 250 bytes, then first pad this data to 256 bytes where the padding has value 0xff. Then send 256 bytes, resulting in sending the equivalent of 258 bytes. Finally the subsequent 'copy RAM to flash command' will copy 256 bytes leaving the 'unused' bytes of the flash page at value 0xff.

Regards,
Vimes

[lpcware]

Content originally posted in LPCWare by Harrie Nijhof on Thu Sep 18 05:54:05 MST 2014
@ OldManVimes:
Thank you for your answer.
It is a pity that neither the manual nor the application note explains why this odd way is chosen. And most wanted, how to work arround this mismatch.
Yes, I know that the mpu works with 4 byte words, so the 4 byte muliples make sense, and the flash works with 256 byte pages so the "minimum 256 byte write" makes sense as well.
But in the application note is an example of a 3-byte write! Is it perhaps that the total of bytes must be a multiple of four?
And, since erasing a flash page gives all ones, would page stuffing with ones be better?
Regards Harrie.

[lpcware]

Content originally posted in LPCWare by OldManVimes on Tue Sep 16 01:32:51 MST 2014
Been there, done that. Yes it is confusing.

There are a number of things that are interacting here. The ISP command to copy data to RAM works on multiples of 4 bytes if memory serves me correctly. The ISP command to copy RAM to FLASH works on multiples of 256 (not 100% sure about that one, but the user manual for your part will have the details).

Then there's UU-encoding where 3 bytes are turned into 4 bytes. Here's what you can do:
- Setup the copy data to RAM command as required (rounding up to multiples of 4).
- If you UU-encode that exact amount of bytes, you may end up with the last UU-encoded frame of 4 bytes that only holds data for 1 or 2 decoded bytes. The way to handle that is to stuff any value into the unused part, but I've read somewhere that the value zero is recommended.

The ISP code will understand that the stuffing is not to be used (based on the 'size' parameter in the earlier copy to RAM command) and does not update the checksum for the stuffing.  That makes sense because the checksum is based on the original non UU-encoded data and that is not padded.

The copy RAM to FLASH command can copy a larger number of bytes than what you wrote to RAM. There does not have to be a perfect match.

I've looked at what FlashMagic does at the serial port level. For a LPC17xx device it uses the following method to copy 512 bytes to FLASH.
- ISP command: Copy 256 bytes to RAM at address 0x10000200
- UU-encode 256 bytes. This results in padding 2 bytes in the last UU-encoded block of 4 bytes.
- checksum check (256 bytes does not generate more than 20 lines of UU-encoded data, meaning there is only one checksum)
- ISP command: Copy 256 bytes to RAM at address 0x10000300
- UU-encode 256 bytes. This results in padding 2 bytes in the last UU-encoded block of 4 bytes.
- checksum check
- ISP command: prepare sector for write
- ISP command: Copy 512 bytes to flash starting from 0x10000200

Hope this clears things up for you.

Regards,
Vimes