Announcements

Equip yourself to optimize PSoc4 MCUs for Evs at the EV Webinar. Click here to register.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

PSoC™ 4 Forum Discussions

DaAd_2521561
Level 2
Level 2
First solution authored 5 replies posted 5 sign-ins

I’m adding a bootloader to my PSOC4 project in PSOC creator, Seem to have the bootloader working and able to program the bootloadable application via the UART using the bootloader host in PSCO creator.

Application runs as expected until I power down the device, it then seems to get stuck in the bootloader and doesn’t jump to the application after the set timeout (wait for command time is set to 2000 in Bootloader component).

Any ideas what might be the issue?  This is what I’m doing:

  1. Program PSOC with Bootloader application
  2. Unload Bootloadable Application via UART (using bootloader host in PSCO creator)
  3. Application is running fine
  4. Turn device off and on
  5. Device remains in bootloader and doesn’t switch to application.
0 Likes
1 Solution
DaAd_2521561
Level 2
Level 2
First solution authored 5 replies posted 5 sign-ins

I found the issue.  I'd managed to select the wrong device type (CY84127AZI instead of CY84147AZI) which must have been messing with the bootloader code.  Been working like this for ages, running the application without any issues, I never though to check this as assumed it would throw up an error if the device chosen in PSoC Creator doesn't match the MCU on the PCB.

Anyway problem solved, thanks for your help.

View solution in original post

0 Likes
12 Replies
BiBi_1928986
Level 7
Level 7
500 replies posted 250 replies posted 250 sign-ins

Hello.

You could try method from this link.  It prevents hangup when trying to go from bootloadable back to bootloader.  It works for me.
Solved: Re: PSOC5LP Reset to Bootloader (without infinite ... - Infineon Developer Community

If bootloader is not jumping to bootloadable after power is applied, is it possible the trigger to jump is being held in the false state?  i.e., a GPIO trigger is being held low  when in fact you want it to be high to allow the jump?

Can you post an image of bootloader component configuration window.

0 Likes
DaAd_2521561
Level 2
Level 2
First solution authored 5 replies posted 5 sign-ins

Thanks for your response.

Attached is an image of the bootloader component.

I'm currently not jumping from bootloadable to bootloader though I do plan to implement a method to do so once I have the bootloader working, so thanks for the tip.

 

0 Likes

Hello.

Thanks or the screen capture.  Looks like you have bootloader component configuration correct.

I was able to replicate your observations.  I added the following line just before Bootloader_Start();
Bootloader_SET_RUN_TYPE(Bootloader_START_BTLDR);

This function call is found in many examples of bootloaders.  It  tells the bootloader to run and wait forever for bootloading commands.  It over-rides the wait for command in component configuration.  At least, that's what I've observed.

By commenting out that line, the bootloader will execute the "wait for command" timer and then jump to bootloadable.

The reason it works (with that function call) using Host Programming Tool, is because Host commands the bootloader to jump to bootloadable immediately after bootloading is complete.  Subsequently, a power ON/OFF cycle causes the bootloader to sit around waiting forever for a command (when that function call is included).

Do you have that line in your bootloader?  Try commenting it out.

0 Likes

No I based the bootloader on the CE221653_PSoC_4_Bootloader_and_Bootloadable example, which simply toogles a LED on then calls Bootloader_Start();

0 Likes

Hi.

CE221653 is an I2C bootloader example.
For UART bootloader, have a look at AN68272.

In my test, I do the same thing, toggle an LED, quickly in bootloader, slowly in bootloadable.  Aside from starting the PWM for LED, I only have the Bootloader_Start() for code.

When you made the bootloadable schematic, did you configure the bootloadable component dependency to point to your bootloader hex file?

0 Likes

Yes I do configure the bootloadable dependencies to point to the bootloader Hex and ELF files.

I took another look at AN68272, the only difference I can spot is I enable interrupts before calling Bootloader_Start() and the example in the app note has it commented out.

I don't have my hardware set-up at the moment so will amend and give it a try when I get chance.

0 Likes

Hello.

I loaded I2C bootloader/bootloadable example from CE221653.  It worked as expected while connected to Creator and when not connected to Creator and perform power OFF/ON cycle.

So, I can only guess that you've programmed the bootloader into PSoC, but for some reason, the Bootloader does not know how to start the Bootloadable.  This can only happen in a couple of different ways.
1. placing the bootloadable at a fixed address
2. pre-programming FLASH which corrupts bootloader tables (Metadata)
3. not pointing bootloader component to correct bootloader hex file
4. setting security bits preventing bootloadable from being programmed into FLASH

I don't really think you're doing any of the above.  I'm sure it's something much simpler.

BTW, why do you call the I2C communication channel UART_IN in the bootloader component configuration window?
That threw me off, thinking you were using a UART bootloader.

What tool do you use to program bootloader into PSoC 4?  Miniprog or Kitprog?

Are you using a Cypress PSoC KIT?  If yes, which one?  Maybe you're missing a jumper or something, like a pull-up resistor?  Who knows?

0 Likes

I am using a UART bootloader which is probably why I've confused you.

I'm using the Miniprog3 to program the bootloader onto the PSOC4, I'm using a custom PCB, but do have a few dev kits I could try.

Thanks for your help.

 

 

0 Likes
DaAd_2521561
Level 2
Level 2
First solution authored 5 replies posted 5 sign-ins

I found the issue.  I'd managed to select the wrong device type (CY84127AZI instead of CY84147AZI) which must have been messing with the bootloader code.  Been working like this for ages, running the application without any issues, I never though to check this as assumed it would throw up an error if the device chosen in PSoC Creator doesn't match the MCU on the PCB.

Anyway problem solved, thanks for your help.

0 Likes
DaAd_2521561
Level 2
Level 2
First solution authored 5 replies posted 5 sign-ins

Actually its not resolved, I had it working with a basic bootloadable example but when I try a more complexed bootloadable application I have the same problem, is there anything in project settings that need to be changed to get it to run the application after power cycle?  

Can't find anything obvious that differs.  The bootloader example calls bootloadable_start after a delay to switch back to bootloader which I've not included in my application as I don't want to switch back to the bootloader at the moment.  I'll keep trying  to find what is different between the example and my application.

0 Likes

Hi.

Does the more complex bootloadable modify FLASH (by calling Em_EEPROM) once it's running?  If yes, then you need to change the config setting Checksum Exclude Section in bootloadable component, otherwise, the checksum calculated by the bootloader will not match the checksum stored in the Metadata bytes.  The bootloader is able to run the bootloadable after being freshly programmed but the checksum fails after a power cycle if FLASH content is modified.

I hope my description wasn't too confusing.

I know you've checked this but, is it still possible you're not pointing the bootloadable component to the correct bootloader.hex file?

And, I assume you have both the bootloader and bootloadable compiler config set to Debug (and not Release)?

 

0 Likes

Yes that's it, I  use Em_EEPROM in the application.

To fix I set the Checksum Exclude Section to match the size of Emulated EEPROM and added CY_SECTION(".cy_checksum_exclude") where I define the EEPROM memory.

Thanks for your help.

0 Likes