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

cross mob
lock attach
Attachments are accessible only for community members.
wcc3
Level 4
Level 4
10 likes received 10 replies posted 5 replies posted

The attached workspace bundle contains two projects:  a bootloader minimally modified from CE216767, Bootloader_DevKit, and a very simple bootloadable, App_Stub_DevKit.  I'm operating with PSoC Creator 4.2, PDL 3.1.4 (though 3.1.0 has the same issue), and the CYBLE-416045-EVAL dev kit.

The release build of the App Stub builds the App Stub against the bootloader's linker command files making it a standalone application in slot 0.  Flash that into the part and it runs.  The green LED on the dev kit is being operated by the M4 core and the red LED is being operated by the M0+ core at a different rate.

Fine so far.

Build the debug build of the bootloader and flash it into the part.  The LED blinks white as it should.

Build the debug built of the App Stub.  This is built against the App Stub's own linker command files which put it in slot 1.  That build also creates the .cyacd2 file.

Use CySmart to load the App Stub .cyacd2 file via the bootloader.  CySmart says it loads fine.  The LEDs don't blink.

Problem:  the application doesn't run.

Go into the App Stub's clock configuration and source Clk_HF0 from path 0 instead of path 1.  Change nothing else.  Rebuild the App Stub.

Reflash the bootloader into the board to destroy the broken App Stub.  Note that I have disabled the button functionality of the bootloader since my real hardware doesn't have a usable button.

Use CySmart to load the rebuilt App Stub into the board.  CySmart says it loads fine.  The LEDs blink correctly.

For some reason, when the App Stub is in slot 0, the PLL clock works.  When it's in slot 1, the PLL clock fails.  Switching the App Stub to the FLL clock enables the App Stub to run in slot 1.

Help, please!

0 Likes
3 Replies
Alakananda_BG
Moderator
Moderator
Moderator
50 likes received 250 sign-ins 250 replies posted

Hi @wcc3 ,

This is a strange issue and we have not come across this before, we will try to debug your code at our end.

Meanwhile  can you  provide us the status of PLL_Init function ?

Regards

Alakananda
0 Likes
lock attach
Attachments are accessible only for community members.

I searched the entire App Stub project for PLL_Init and came up with nothing.  I don't believe that the function exists.

The PLL initialization appears to be done in function ClockInit() in module cyfitter_cfg.c.

The debugger isn't useful here because of the software reset that occurs after App Stub is loaded by the bootloader.  Likewise, any serial ports that I define are probably either uninitialized or unusable while the clock tree is being brought online.

So I defined two I/O output pins, SCK and MOSI, and bit-banged the return values from functions Cy_SysClk_PllManualConfigure() and Cy_SysClk_PllEnable() out most-significant byte first over those pins.  Here is the result:

Bit-banged function return valuesBit-banged function return values

Cy_SysClk_PllManualConfigure() returned 0.  Cy_SysClk_PllEnable() didn't return at all, at least not within the 7.68ms of trace that I could capture.

I've attached the instrumented module cyfitter_cfg.c. 

0 Likes
wcc3
Level 4
Level 4
10 likes received 10 replies posted 5 replies posted

Turns out the clock pulses are 120ns wide, so I could lower my sampling rate and see more time.  Cy_SysClk_PllEnable() does not return after 96ms.

0 Likes