What should we check when controller does not run the program?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mostafanfs on Sat Apr 23 04:45:17 MST 2016
Here's the deal :
I have a LPC1778 board and I'm sure it's working fine. I use IAP functions. the thing is sometimes after reset the controller runs the new program just fine and sometimes it does not run the code at all !!
I have a bootloader code located at the last sector (sector #29) and I'm not planning on changing that sector. But other sectors (0 ~ 28) may be updated by the bootloader code all the time.
Could that be a problem? (because of the crc or checksum or something else? )

Now I looked and from the documents it seems that controller tries to verify the code located on internal flash first to make sure it's what it should be (determined by the checksum word) and then it jumps to that code.
But I don't know how it does that because I checked and checksum word (4 bytes located at 0x1c address) is just a checksum of previous bytes located at 0x00 through 0x1B .
What about the rest of the code?

I mean what if I changed the code located at last sector just randomly. How can this error be detected by the flash verifying process?
Look at the picture. It's obvious that checksum word is just a checksum from those selected bytes :

[img]https://i.imgsafe.org/3d36873.png[/img]

lpcware · ‎06-18-2016

bump

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mostafanfs on Fri Apr 29 22:29:11 MST 2016
Thanks man.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by bavarian on Fri Apr 29 02:55:46 MST 2016
The IAP functions are in ROM, they belong to the bootloader code. So there is no need from your side to place them somewhere in RAM nor to reserve things.
The IAP functions requires some amount of RAM to work with. And this is the 32-byte section the user manual mentions. In all our platforms it is the top 32 bytes from the first RAM block. For the LPC1778 it's the RAM block starting at 0x1000 0000. If you call IAP, then these 32 bytes will be used for relocating a small program, which runs when erase/program operations on the flash take place. At these times execution from flash would be impossible, so it must be done from RAM (please note that the bootloader code is also in flash, in a hidden sector).
You only need to tell the linker that the available RAM is at 0x10000000 with size (64kbytes - 32) in order to prevent the linker to provide these 32 bytes to the normal application code.

Regards,
NXP Support Team

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mostafanfs on Thu Apr 28 10:08:16 MST 2016
Yeah, Thanks.
The thing is I know how to place a bunch of functions in a specific part of flash using editing linker file in IAR (*.icf file).
But I don't know how to do that for IAP RAM. I mean how to reserve space in RAM for IAP functions in IAR linker file.
By the way what does this phrase " top 32 bytes of on-chip RAM" mean? What exactly addresses are we talking about?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by bavarian on Thu Apr 28 06:40:18 MST 2016
If the debugger offers to connect to the target without a reset (no hardware reset, no verctor reset c etc), then you should be able to catch the core in its current state and look at the system flags. LPCXpresso, IAR, Keil, Lauterbach, they all can do this.

I didn't read through the whole thread, but when it comes to stack/heap usage and IAP routines, are you sure that you excluded the bytes in RAM which are used by IAP from the available space for the linker? If this overlaps, then you might experience problems.

User manual, chapter "RAM used by IAP command handler"

"Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
usage in the user allocated stack space is 128 bytes, growing downwards."

Regards,
NXP Support Team

lpcware · ‎06-15-2016

Content originally posted in LPCWare by vtw.433e on Tue Apr 26 11:57:41 MST 2016
According to
http://supp.iar.com/FilesPublic/UPDINFO/004916/arm/doc/infocenter/csarmjlink.ENU.htm

V5.10 released in 2007 supports attaching to a running system. Suggest you learn how to use your tools!

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mostafanfs on Tue Apr 26 09:09:43 MST 2016
Thank you.
Great notes.
That would be a good feature in LPCXpresso . I don't believe IAR has such capability.
My project is in IAR. Would that be possible to use LPCXpresso just for this matter? (connecting to a running system and observing registers, stack, memory, ...)
I mean is it important that program was written in which compiler?
I'm talking about free edition of LPCXpresso .

lpcware · ‎06-15-2016

Content originally posted in LPCWare by vtw.433e on Mon Apr 25 00:07:09 MST 2016
The only checking that is done by the NXP ROM bootloader is the vector checksum at address 0x1c. This is just the 2s complement on the preceding words. LPCXpresso can set this for you automatically, but I don't know if IAR does.

But rather than all of this guessing, you need to connect a debugger to a system that is not running to find out what has gone wrong. I don't know about IAR but LPCXpresso allows you to connect to a 'running' system (i.e. it will not download to the flash, and it stops the processor running so you can examain the resgisters, stack, memory etc).

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mostafanfs on Sun Apr 24 21:22:47 MST 2016
What about Flash Signature Generator module?
What does it do?
Is it necessary to generate a signature after calling IAP functions and updating flash contents?
I saw that in IAP examples from NXP in a way the compute a signature after IAP.
Does that have anything to do with verifying flash contents after a reset? (so it could result in a failure start-up? )

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mysepp on Sun Apr 24 01:29:53 MST 2016
Just as hint: In User Manual of LPC1778
( http://www.nxp.com/documents/user_manual/UM10470.pdf )
chapter 37.3.2.10 on page 881:

37.3.2.10 RAM used by IAP command handler

Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
usage in the user allocated stack space is 128 bytes, growing downwards.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mostafanfs on Sun Apr 24 00:15:45 MST 2016

Quote:
If you are in the situation that it does not work, does it work again (without flashing again) when you power cycle?

No it just blows and powering off and on does not help.

Quote:
Have you checked if everything you want to write into flash is really written there, e.g. not last sector/bytes missing or similar?

Yes I did a readback from sector#0 ~ sector#28 using jlink jflash and saved bin file and compared it and turns out all of it was written in flash there correctly. (compared against my bin file which was written into flash)

Quote:
Can you somehow see and check if you really do a reset and that it is not hanging in some of the exceptions?
Have you taken into account, to disable interrupt before calling IAP?
Have you given IAP its needed memory area?

All interrupts are disabled.
I didn't do anything about IAP required RAM because when everytime I run the code in a debugger I see that there is no problem with IAP functions and they do their job just fine. Maybe it's by chance. I don't know. But for the sake of the argument could please tell me how to do that?
I searched for this before and there is only a guide in NXP site for LPC Expresso but I'm using IAR.

Quote:
Do you use a (JTAG) debugger? Or perhaps a serial port? Or even a LED for debugging?
Have you checked you reach reset handler after your watchdog reset?
If debugger, where are you staying (PC program counter) when it is not working?
Does it behave the same when debugger is connected as well as debugger is not connected?

Of course. I use J-Link. well after updating flash and after watchdog reset the debugger gets lost somehow because it does not have the control of program anymore and it does not know what to do. I mean after reset you don't get to use debugger anymore because debugger loads program data on it's own and you can't expect more of it. It just gets lost and it seems reasonable.
And therefore it doesn't show a correct PC.
When it's not working it doesn't make any difference to connect or not to connect debugger.

I read USB secondary bootloader documents. There was no new subject. All they cared about was assigning SP and PC and VTOR. Just like I did. The only difference is that I point to 0x00000000 (sector#0) instead of 0x00002000 (sector#2)

Edit :
Now I wrote a simple __ASM function loading SP and PC with the correct addresses and called it after finishing IAP calls. For now it's working fine. But I'm not sure that was the reason because when I power off then on the system after calling IAP functions without calling __ASM function (assigning to SP and PC) it works fine either. I mean a reset assign SP and PC with the proper value considering I put my code at 0x00000000 since it is default value for controller and I don't need to assign them myself

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mysepp on Sat Apr 23 11:50:44 MST 2016
If you are in the situation that it does not work, does it work again (without flashing again) when you power cycle?

Have you checked if everything you want to write into flash is really written there, e.g. not last sector/bytes missing or similar?

Can you somehow see and check if you really do a reset and that it is not hanging in some of the exceptions?
Have you taken into account, to disable interrupt before calling IAP?
Have you given IAP its needed memory area?

Do you use a (JTAG) debugger? Or perhaps a serial port? Or even a LED for debugging?
Have you checked you reach reset handler after your watchdog reset?
If debugger, where are you staying (PC program counter) when it is not working?
Does it behave the same when debugger is connected as well as debugger is not connected?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mostafanfs on Sat Apr 23 11:33:41 MST 2016

Quote:
Sorry for going back, but is it correct that you are not using a bootloader at all?
You have just some function which can write flash (IAP) put into a certain sector?

That's true. Suppose you have configured a USB Host on your controller and you want to update firmware whenever you want using a USB Flash Stick. You just put bin file into USB Stick and load it's data. You may call this a bootloader or you may not.

Quote:
You write: It works sometimes, sometimes not.

What have you done, just before the error occurs and what are you doing when the errors occurs?
Have you changed something which produces this error, a change something to go it away.
Or always the same program, you just press HW (?) reset and sometimes it works, sometimes not, always with same content?
Or do you perhaps update some parts in flash and then it does not work anymore,
and when you do a reset, the error is away till you again change the flash?

No. Not with a same firmware. I mean when a firmware is working, it's working forever and no problem there. When I change a firmware it may blows the execution after reset. I strongly believe I'm blowing something like a vector or Stack Pointer and thing like that. Or as I said a CRC or checksum checking that will force the controller NOT to execute flash contents. That's the deal.

Edit :
I checked in user manual and seems like SP and PC are getting their default and correct value after a watchdog reset. In page 808 it says :

Quote:
When the Watchdog Timer is configured so that a watchdog event will cause a reset and the counter reaches zero, the CPU will be reset, loading the stack pointer and program counter from the vector table as in the case of external reset

So @vtw.433e could it still be my problem? (I will test on hardware first thing in the morning)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mysepp on Sat Apr 23 11:16:42 MST 2016
Sorry for going back, but is it correct that you are not using a bootloader at all?
You have just some function which can write flash (IAP) put into a certain sector?

You write: It works sometimes, sometimes not.

What have you done, just before the error occurs and what are you doing when the errors occurs?
Have you changed something which produces this error, a change something to go it away.
Or always the same program, you just press HW (?) reset and sometimes it works, sometimes not, always with same content?
Or do you perhaps update some parts in flash and then it does not work anymore,
and when you do a reset, the error is away till you again change the flash?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mostafanfs on Sat Apr 23 10:46:08 MST 2016

Quote: vtw.433e
This is almost certainly your problem.

Your boot loader needs to set up the stack pointer for your application, otherwise it will use the same one that your boot loader uses. It doesnt matter what the linker script does, as somebody has to set the SP register to the correct value.

When a cortex-m device boots (normally) the SP is in address 0, followed by the initial PC at address 4. Your boot loader should mimic this behaviour when starting the application.

Keep in mind that when I'm done copying data from RAM to sectors (0 ~ 28) I force the controller to reset using internal watchdog. So it would begin executing from 0x00000000 after reset. So I figured SP has been assigned by a correct value automatically after a reset! (I should mention again that sometimes it works!)

Now what are you saying? That I'm supposed to assign a value to SP register manually after copying data (before reset) ?
If that is the case then how and what value should I assign to SP ?
Just writing SP = 0x00; is enough ?
What about PC ?

Edit:
I guess SP is not available through C/C++ and I'm supposed to use assembly language to load a value into SP. I checked the AN10866 sources and they used this function :

__asm void boot_jump( uint32_t address ){
   LDR SP, [R0];Load new stack pointer address
   LDR PC, [R0, #4];Load new program counter address
}

I take it that R0 has the same value as 'uint32_t address' , right ?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by vtw.433e on Sat Apr 23 10:02:36 MST 2016
This is almost certainly your problem.

Your boot loader needs to set up the stack pointer for your application, otherwise it will use the same one that your boot loader uses. It doesnt matter what the linker script does, as somebody has to set the SP register to the correct value.

When a cortex-m device boots (normally) the SP is in address 0, followed by the initial PC at address 4. Your boot loader should mimic this behaviour when starting the application.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mostafanfs on Sat Apr 23 09:07:06 MST 2016

Quote: vtw.433e
How are you setting up the stack?

Actually I don't know how to do that. But it's a default value:
Linker file in IAR :

define symbol __ICFEDIT_size_cstack__ = 0x800;
define block CSTACK with alignment = 8, size = __ICFEDIT_size_cstack__ { };
place in RAM_region { readwrite, block CSTACK };

It's located in RAM so I don't think it has anything to do with my problem. Wouldn't you ?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mostafanfs on Sat Apr 23 09:00:59 MST 2016
> Ok, the Reset-Handler of the Bootloader or of the Application?
-- Reset_Handler of the application. The Bootloader does not have a Reset_Handler because there is no use for it since my Bootloader DOES NOT start after powering the controller or even after any kind of reset. My bootloader is just a simple function and only use and calls a couple of IAP functions. That's all. It doesn't have anything to do with the interrupts or Reset and so on. All Interrupts are disabled before calling that function. Unlike the secondary USB bootloader that you mentioned which is really a Bootloader and starts executing whenever the controller is powered or has been reset.

> The address of 0x00000004 to 0x00000007 is taken (beside some checks) to start code in flash.
If this is the address of the Reset-Handler of the application, then bootloader is not started at all.
-- Same answer as above answer.

> It could be easier and more clear, if you put your bootloader into sector 0.
How exactly is that gonna make a difference?
Well I thought of that too but I figured it would be easier to put the code in sector#29 and NOT messing or screwing with sector#0 and Interrupt Vector Table and things like that. That's why I put my code there. Besides at first I figured that the code is likely gonna need more than 4KB so better to put it in a 32KB sector. Although it turns out 4KB is pretty enough.

> I think there is an application note AN10866, have a look, perhaps it is helpful.
( http://www.nxp.com/documents/application_note/AN10866.pdf )
especially Fig. 4 on page 8.

-- I've seen that before. And it's SORT OF like what I'm doing. I just changed numbers and addresses according to my design.
I mean hell it was even working for the most part.

If I couldn't make it this way I will put the code in sector#0 like you said and see how things work out.
But if you have something else in your mind please bring it here.
thanks

lpcware · ‎06-15-2016

Content originally posted in LPCWare by vtw.433e on Sat Apr 23 08:48:50 MST 2016
How are you setting up the stack?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mysepp on Sat Apr 23 05:48:55 MST 2016
> And also 0x0005E251 is NOT the start address of bootloader. It's the start address of the Reset_Handler .

Ok, the Reset-Handler of the Bootloader or of the Application?

The address of 0x00000004 to 0x00000007 is taken (beside some checks) to start code in flash.
If this is the address of the Reset-Handler of the application, then bootloader is not started at all.

If it is the Reset-Handler of the bootloader, then you can do what you want in Bootloader (e.g. update application in flash)
and finally jump to application.

Is this similar to your environment?

"Merge": Make a list what is contained in Sector 0. What is needed for Bootloader, what is needed for application? And how does the info get there?
It could be easier and more clear, if you put your bootloader into sector 0.

I think there is an application note AN10866, have a look, perhaps it is helpful.
( http://www.nxp.com/documents/application_note/AN10866.pdf )
especially Fig. 4 on page 8.

What should we check when controller does not run the program?

What should we check when controller does not run the program?

LPC17xx