LPC11C22 - start user program through CAN boot loader

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

LPC11C22 - start user program through CAN boot loader

1,425 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by kitt on Thu Nov 21 08:14:13 MST 2013
Hello all,

we've seem to have run into a problem with starting a (valid) user program through the CAN ISP boot loader.

Our current design consists of an LPC11C22 with both PIO0_1 and PIO0_3 pulled to ground. Upon powerup, the LPC11C22 successfully enters the CAN boot loader mode and is responsive to commands sent from another LPC17xx board over the CAN bus. However, the final step - actually booting user code - is not happening.

First of all my CAN command and response sequence sent on the CAN bus:

> [0x67D] [0x2B 0x00 0x50 0x00 0x5A 0x5A 0x00 0x00] // unlock flash
< [0x5FD] [0x60 0x00 0x50 0x00 0x00 0x00 0x00 0x00]
> [0x67D] [0x23 0x70 0x50 0x01 0x00 0x00 0x00 0x00] // set execution address
< [0x5FD] [0x60 0x70 0x50 0x01 0x00 0x00 0x00 0x00]
> [0x67D] [0x2F 0x51 0x1F 0x01 0x01 0x00 0x00 0x00] // 'Go'
< [0x5FD] [0x60 0x51 0x1F 0x01 0x00 0x00 0x00 0x00]

We've verified the sequence above by using a logic analyser behind the CAN transceiver on the LPC17xx board.

Some additional comments:
* if we lift PIO0_1 before powerup the user program is successfully started
* normally PIO0_1 is never lifted when issueing the commands above, nor is PIO0_3. We tried lifting PIO0_1, but that didn't seem to help anyways.
* We can successfully read the part ID when sending
> [0x67D] [0x40 0x18 0x10 0x02 0x00 0x00 0x00 0x00]
reply:
< [0x5FD] [0x43 0x18 0x10 0x02 0x2B 0x10 0x31 0x14]

Are we missing something or should this work?
Labels (1)
0 Kudos
29 Replies

1,089 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by 1234567890 on Sun Nov 24 03:07:19 MST 2013

Quote: kitt
However, the final step - actually booting user code - is not happening.

A little bit offtopic to your question: Why don't you use 'Reinvoke ISP (IAP)'? You don't need any external components or physical contact to the chip. Pure software for reprogramming via CAN.
0 Kudos

1,089 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mhg on Mon Dec 08 02:29:23 MST 2014

Quote: "LabRat"
The solution is to switch you 100k node to 250k. This can de done with CAN-ISP.


ISP command "Set Baud Rate" is n/a for C_CAN usage (see UM Table 392).


Quote: "LabRat"
Unfortunately this means that you have to switch off your 250k nodes meanwhile


Which is often not possible running systems with third party components off-the-shelf.


Quote: "LabRat"
So a 250k secondary bootloader is a better approach


Reimplementing the on-chip code just to change the BTR setting has a bad cost-value ratio  ;-)
Updating the secondary bootloader will cause additional efforts. I would prefer to use the well tested NXP code instead of reimplementing it.

R2D2 pointed an interesting fact and as he proposed i have started a new thread because this is no longer matching the threads headline.
0 Kudos

1,089 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by LabRat on Fri Dec 05 07:24:02 MST 2014

Quote: mhg
Now the bootloader is running with CAN interface set to 100k on a bus with all other nodes using 250k.
Does anyone found a solution?



The solution is to switch you 100k node to 250k  :O

This can de done with CAN-ISP  :)

Unfortunately this means that you have to switch off your 250k nodes meanwhile (or you're running 2 different baudrates, which is causing problems)...

So a 250k secondary bootloader is a better approach  ;-)
0 Kudos

1,089 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mhg on Fri Dec 05 05:48:45 MST 2014
Anyone found a solution after half a year ?

An LPC11C24 connected to a CAN bus operated at 250k is getting the command to start its bootloader for firmware update over CAN. The bootloader is started by:

unsigned int Command[5];
unsigned int Result[4];
/* Set PIO0_1 and PIO0_3 as output low (ISP by CAN) */
Chip_GPIO_SetPinDIROutput(LPC_GPIO, 0, 1);
Chip_GPIO_SetPinDIROutput(LPC_GPIO, 0, 3);
Chip_GPIO_SetPinOutLow(LPC_GPIO, 0, 1);
Chip_GPIO_SetPinOutLow(LPC_GPIO, 0, 3);
/* Disable interrupt in VIC */
NVIC_DisableIRQ( CAN_IRQn );
/* Disable interrupts for selected pins on a port */
Chip_GPIO_DisableInt( LPC_GPIO, GPIO_PININT_PORT, 0xFFFFFFFF );
/* Switch to IRC */
Chip_Clock_SetMainClockSource( SYSCTL_MAINCLKSRC_IRC );
/* Send Reinvoke ISP command to ISP entry point*/
Command[0] = 57; /* see 26.7.8 */
/* Set stack pointer to ROM value (reset default) */
__set_MSP(*((uint32_t *) 0x1FFF0000));
iap_entry( Command , Result );


Now the bootloader is running with CAN interface set to 100k on a bus with all other nodes using 250k.
Does anyone found a solution (other than reimplementing the bootloader functionality as pointed by 1234567890) ?

Thanks in advance.
0 Kudos

1,089 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by robotman on Thu Aug 28 09:59:12 MST 2014
Thanks, R2D2, this sound like what I want to do, but I'm not sure how it would work.

There are numerous devices on the CAN bus running at 250kbps. If my device calls Reinvoke ISP, the C_CAN bootloader begins running and sets the CAN bit rate to 100kbps. How can I change the BTR settings? My code is no longer running and the CAN bus now has devices running at two different bitrates which, as LabRat pointed out, is likely to cause errors.

Am I missing something?
0 Kudos

1,089 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by 1234567890 on Wed Aug 27 12:56:51 MST 2014

Quote: R2D2
If you want to use higher baudrates with C_CAN bootloader, change BTR settings.



Could you please describe the sequence a little bit more detailed, like
- invoke bootloader with command Reinvoke ISP (IAP)
    -> CAN bitrate is now 100 kbit/s
- ...
?
0 Kudos

1,089 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by R2D2 on Wed Aug 27 08:02:34 MST 2014
robotman,

I know you are a busy engineer, so I'll make it short:

The fastest workaround has been mentioned already  (I don't quote the UM again, don't want to get a 'not helpful')  0:)

If you want to use higher baudrates with C_CAN bootloader, change BTR settings. Not sure which baudrates you are trying to use, but it's also useful to switch from IRC to crystal  ;-)

Note: That's no theory, that's really working  :O

BTW: Please start a new thread, this one is old and long enough...
0 Kudos

1,089 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by 1234567890 on Mon Aug 25 12:47:10 MST 2014
Sorry, robotman, I haven't read your question carefully enough. I've just read IAP:


Quote: robotman
Section 26.6 of the LPC11Cxx user manual states that the C_CAN boot loader sets the CAN bit rate to 100 kbps. Will Reinvoke ISP (IAP) do the same thing? If so, can Reinvoke ISP be used for reprogramming within a system where the CAN bus is operating at a higher frequency and other CAN devices are active on the bus?



Because I haven't tested yet it's not the ultimate answer you asked for: Reinvoke ISP (IAP) does invoke the bootloader and therefore sets the bitrate to 100 kbit/s like LabRat wrote.
But it should be possible to update your node at your bitrate: Simply don't use Reinvoke ISP (IAP)! You have all the IAP commands to write the flash and don't need the bootloader. Then you talk to the node with your ID and your bitrate and all your settings...
Because if you write to flash you (can) overwrite your own code you have to take care of the vectortable (if needed), have to place a few functions to RAM (e.g. your update functions, NVICSystemReset to reset after flashing), don't use reserved regions in RAM for IAP and so on.
0 Kudos

1,088 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by robotman on Mon Aug 25 10:03:59 MST 2014

Quote:
Are you kidding me?

If you don't believe me I would suggest to try it yourself or read the UM:



Sorry, throwing back the exact same section of the UM that I started my question with is not helpful. Anyone with experience knows that written technical documentation can be incomplete, misleading, or plain wrong. I'd rather hope that the documentation is incomplete or wrong than believe that NXP engineers would lack the foresight to see how resetting the bit rate in a running system could be a problem. I appreciate your taking the time to respond, but unless you have firsthand (not just UM) knowledge that the bit rate is indeed reset under Reinvoke ISP or have a suggestion on how to work around it, I'd prefer to hear from someone who does.  As for just trying it myself, the point of forums like this is so that busy engineers don't have to re-solve the same problems that others have already faced.
0 Kudos

1,089 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by LabRat on Sat Aug 23 18:39:09 MST 2014

Quote: robotman
Does anybody have the definitive answer?



Are you kidding me?

If you don't believe me I would suggest  to try it yourself or read the UM:


Quote:
26.6 C_CAN communication protocol
Remark: The C_CAN interface is available on LPC11Cxx parts only.
The C_CAN bootloader is activated by the ROM reset handler automatically if PIO0_3 is
LOW on reset and the ISP entry enabled (PIO0_1 LOW). [color=#f00]The C_CAN bootloader
initializes the on-chip oscillator and the CAN controller for a CAN bit rate of 100 kbit/s
[/color]and
sets its own CANopen Node ID to a fixed value. The bootloader then waits for CANopen
SDO commands and responds to them. These commands allow to read and write
anything in a so-called Object Dictionary (OD). The OD contains entries that are
addressed via a 16-bit index and 8-bit subindex. The command interface is part of this
OD.

0 Kudos

1,089 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by robotman on Sat Aug 23 18:07:45 MST 2014
Thanks for the replies, however contradictory they are. I understand the confusion, as I am likewise confused.

1234567890 says that the bit rate won't change, which is what would make most sense, is what I am hoping for, and would allow for CAN IAP in most applications.

LabRat says the opposite: the bit rate WILL be set to 100kbps in which case other devices on the bus operating at the original, higher frequency, will cause errors. This would seem to be a fatal flaw in CAN IAP for these parts.

Does anybody have the definitive answer? How do you know?

Thanks in advance.
0 Kudos

1,089 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by LabRat on Sat Aug 23 08:16:06 MST 2014

Quote: robotman
Section 26.6 of the LPC11Cxx user manual states that the C_CAN boot loader sets the CAN bit rate to 100 kbps. Will Reinvoke ISP (IAP) do the same thing?



Yes, IAP57 (Reinvoke ISP) is doing exactly what's described in UM  :D


Quote:
This command is used to invoke the bootloader in ISP mode.



If PIO0.3 is low, C_CAN Bootloader is started, otherwise UART Bootloader...


Quote: robotman
If so, can Reinvoke ISP be used for reprogramming within a system where the CAN bus is operating at a higher frequency and other CAN devices are active on the bus?




It's not recommended to do that. Active CAN devices could interpret a different baudrate as error  :O
0 Kudos

1,089 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by 1234567890 on Sat Aug 23 02:09:59 MST 2014
I don't think that the bootloader is called when using IAP. The relevant register values (like bitrate) remain unchanged. The bootloader is called after a reset and sets the bitrate to have a known frequency to operate.
When using IAP you are responsible for the bitrate.
0 Kudos

1,089 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by robotman on Thu Aug 21 16:37:08 MST 2014
Section 26.6 of the LPC11Cxx user manual states that the C_CAN boot loader sets the CAN bit rate to 100 kbps. Will Reinvoke ISP (IAP) do the same thing? If so, can Reinvoke ISP be used for reprogramming within a system where the CAN bus is operating at a higher frequency and other CAN devices are active on the bus?
0 Kudos

1,089 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by robotman on Wed May 14 15:39:36 MST 2014
Of course, I realized the answer as soon as I hit 'Post': program all nodes with unique, not 0x7d, ids and only have a single node enter ISP at a time.
0 Kudos

1,089 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by R2D2 on Wed May 14 15:34:37 MST 2014

Quote: robotman
If I have multiple nodes on a CAN network, how would I program them...



One after another  :)
0 Kudos

1,089 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by robotman on Wed May 14 15:24:28 MST 2014
When using "Reinvoke ISP", is the node id still always 0x7d used as described in section 26.6? If I have multiple nodes on a CAN network, how would I program them if they all use the same node id?
0 Kudos

1,089 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by kitt on Mon Nov 25 05:44:44 MST 2013
Well thank you for your suggestion. Disabling and clearing all interrupts before moving the stack pointer and calling the IAP did the trick. We're now able to go to ISP mode using the IAP from user code.

Many thanks for the help!
0 Kudos

1,089 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by R2D2 on Mon Nov 25 04:19:24 MST 2013
Not sure what your code is doing. I would suggest to run the original sample. If that's working your code could be the problem.

A usual way to avoid problems with stuff like this (enabled interrupts / watchdog) is to reset the chip before IAP57...
0 Kudos

1,089 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by kitt on Mon Nov 25 04:09:27 MST 2013
Setting the stack offset was something I had forgotten about. After correcting it, still no luck.

I'm not running the "invokeisp" example itself. I basically took the invokeisp_main.c file, commented the main() section and kept the rest.

When I receive a command from the CAN bus to go to the ISP mode I set a flag that is picked up by my own main loop. Main() then calls ReinvokeISP() which should put the CPU in ISP mode through IAP. Using the debugger it does seem the CPU is executing the ROM boot code. However, still no reply to my part ID request, even after a wait of a couple of seconds.
0 Kudos