Bootloader's "G" command slightly broken?

[lpcware]

Content originally posted in LPCWare by Floyd42 on Thu Mar 20 10:35:52 MST 2014

If the "G" command it succeeds, then it just send a "0", but not the CR LF chars. All other commands send a CR LF after the return code.
Seen on a LPC810M021FN8, Boot Loder: V13.4

Is this a know limitation or a bug? Would be nice if a new rev of the the user manual would mention this detail.

[sanderverhage]

I have tested to execute a very simply program (Only BX LR at address 0x10000300) in RAM. I believe this shouldn't influence the ISP software, but I receive two bytes 0x30 followed by 0xFF. From other test programs (setting a LED) I know the software executes. After code execution ISP doesn't respond to commands any more. 

So the LPC800 doesn't respond with 0x30, 0x0D, 0x0A, which can be worked around and therefore isn't such a problematic issue. What is important in this matter is making an announcement about the future. It's an issue that will be fixed and therefore only present in version 13.1, .... or it's a new ISP feature, which from now on will be included in every ISP release. So NXP, please make up your mind and be clear about these changes/issues (Also inform about the binairy data transfers, which are not conform the ASCII protocol with UU encoding, used in previous ISP bootrom's). 

A larger problem is that after receiving the response, ISP no longer responds to commands. This way it's not possible to execute code snippets, which access hardware, normally not available using the ISP ROM. For example a serial EEPROM , containing configuration data, connected to the device using I2C. I have used such programs a lot on LPC17xx and LPC21xx devices and never had any problems.

Sander

[mark_stokes]

I have also seen the GO command work differently than the manual.  As Axel indicates, the manual indicates we can't use addresses under 0x0200.  However, in my experience, I am using the command: "GO 0 T" (That's 'G' 'O' 'Space' 'Zero' 'T') and it's working perfectly.  Including setting the stack.  So, am I getting lucky?  Or is this dangerous?

Thanks

-Mark

[lpcware]

Content originally posted in LPCWare by Floyd42 on Wed Mar 26 06:12:32 MST 2014
Marc,


thank for the explanation, that exp(l)ains a lot. I will update my flashing script to handle this better.

Reading the docs, there is another wired thing about the G command:

---

Quote:

The command must be used with an address of 0x00000200 or greater.

---

Where does this magic flash address comes from?
And another documentation improvement: shouldn't this says something about RAM also, ie that 80 byte from 0x10000000 to 0x10000050 are not use by bootloader and thus are safe. But there might be other areas also that can be used without going into a bootstrapping aproach here?

Axel

[lpcware]

Content originally posted in LPCWare by MarcVonWindscooting on Tue Mar 25 09:33:54 MST 2014

---

Quote: dztang
Go command does send LF/CR just like the rest of the commands. The problem
Is user code can do anything they want, the data may get stuck or terminal
may stop respond after user code change the clock, the baud rate, or toggle the TX/RX line.

That's why GO is acting differently from the rest of the commands.

---

But the implementor(s) of the ISP handler know this. That's why they shouldn't start the user code, before all characters have left the UART for sure. If they do, then it's a bug.

Rather than accepting different responses from the ISP handler, I'd rather load a piece of code into RAM that first does a busy delay (to drain the UART) and then performs a RESET.

[lpcware]

Content originally posted in LPCWare by dztang on Tue Mar 25 09:14:42 MST 2014
Go command does send LF/CR just like the rest of the commands. The problem
Is user code can do anything they want, the data may get stuck or terminal
may stop respond after user code change the clock, the baud rate, or toggle the TX/RX line.

That's why GO is acting differently from the rest of the commands.

[lpcware]

Content originally posted in LPCWare by Floyd42 on Mon Mar 24 17:09:12 MST 2014

Trying at different baud rates, it is really wired what comes back sometimes. Nicest thing I've see so far is reading a hell lot of digits there. So now my approach now is:
* read one char. "0" is ok, andy other digit is likely an error code.
* 2nd char "0" - "9" is ok. anything else is error
* basically assume reboot worked if answer wired

Anybody from the bootleader team willing to comment here? I tried disassembling it, but is it really worth the time....?

Axeö