AnsweredAssumed Answered

No IRQ working after a Go Command from ISP (lpc8xx)

Question asked by Olivier Le Doeuff on Apr 25, 2018
Latest reply on Aug 28, 2018 by jeremyzhou

Hi everyone, i'm issuing a problem that is a little bit disturbing.

I'm writting a software that use the uart ISP API from lpc824. When i'm trying to send the command Go : "G <address> T\r\n" the program in flash execute with a major problem: No irq are working at all.

I've tried with differents programs from lpc open (compiled with mcuxpresso ide/gcc). In the document it says that the go command shouldn't be lower that 0x200 but it seem to work. First i thouhgt that this might be the reason but after lanching a program that have the resetISR after 0x200 still it was working.

I already read this post : ISP Command manual bugs and the guy was saying that it was working for him.

The problem isn't a big deal because if i reset the mcu then the program work just fine. So what is happening here?

 

My idea is that the bootloader is configuring the mcu in a certain way that deactivate the irq or something like that but i don't know ARM architecture enough to find what is happening myself?

I've tried a __enable_irq(); in the program still it didn't work.

 

Also i've noticed couple of strange behavior in the communication with the ISP bootloader that are not explained/ error inside the datasheet.

- When sending the ReadBootCodeVersion command the process is describe in datasheet as:

-> "K\r\n"   // Send command from host

<- "0\r\n"   // CMD_SUCESS from target

<- "<major><minor>\r\n" // should be interpreted as <major>.<minor> with <major> a single byte and same for <minor>

But what is see is :

-> "K\r\n"   // Send command from host

<- "0\r\n"   // CMD_SUCESS from target

<- "<major>\r\n"   // "1\r\n" in my case

<- "<minor>\r\n"   // "13\r\n" in my case

And now i'm not sure which one is the major or the minor because in the post ISP Command manual bugs posted a screenshoot from flashmagic showing that the version of his bootloader program was 13.1.

Also i confirm what is said in the other post that the command WriteToRam doesn't answer "OK\r\n" after receiving the plain binary data. Is this problem recurrent to the whole LPC series or only the lpc8xx series?

 

These are not critical problems because : 

- a simple reset can fix the go command.

- ReadBootCodeVersion isn't very important in my situation

- WriteToRam i just have to not wait the "OK\r\n"

 

But i really want to understand what can possibly go wrong with the go command, if this is a problem from my software that isn't resetting enough stuff or is it really a bug inside the lpc.

Thanks a lot for you attention and your possible answers.

Outcomes