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

PSoC™ 4

DaGa_4378306
Level 4
10 replies posted 5 replies posted 5 questions asked
Level 4

I have a startup problem with the PSCO4 BLE module, here is the functionality:

  1. It is a sealed unit, with an internal LiPo battery, and externally I can only provide 5V to charge
  2. It appears that from a dead battery, if you start charging there is maybe 1 in 20 chance, PSOC4 hangs and doesn't start up properly
  3. The battery now has some charge, and I can't access XRES pin easily (you have to remove a few things to get to the signal). It looks like you need to let the battery fully discharge and then try again to power up the next day
  4. The external way you know it's charging is if the firmware checks a GPIO from the charging IC, and then turns on an LED, I can see the charge current going into the battery (charging IC is working), but firmware is not working
  5. The project supports an OTA update (fixed stack bootloader)

 

So my question is this:

  • If I enable the Watchdog timer Hard reset in the firmware image -- is that enabled at power-up,  or is it still a firmware step to enable the watchdog per the FLASH image?
  • I had this slight hope that the watchdog could help if the firmware hung, and issue the reset to the device -- but if it requires firmware to enable the watchdog, it may never get to that step.
  • Same question with the brown-out detection circuit, does that require a firmware step to program at power-up
  • Is it possible that it is hanging in the bootloader section first 

I already have many units built, and I have no real ability to redo HW right now (very painful). I can easily update the main firmware image, but changing the bootloader is also very hard. 

Any thoughts on the firmware watchdog solution?

 

 

0 Likes
1 Solution
Len_CONSULTRON
Level 9
1000 replies posted 750 replies posted 500 likes received
Level 9

DaGa,

Interesting issue!

I may not be the best expert on this issue but I'd like to start the discussion.

Can you replicate this issue with on-hand units?   If so, there might be ways to know where the CPU is hanging.  In the application or the bootloader.

If the PSoC4 is hanging in the application, there are some changes that might improve the issue.  Launching the WDT very early in the process BEFORE starting different components in particular the BLE component.

As each component is started (with the required clocks) more current is used.  A depleted battery with a high internal source resistance will drop the voltage to VDDD, VDDIO and VDDA.  This could be a problem causing the 'hang'.  Forcing the WDT early could at least provide multiple restarts of the code.

In addition to the early WDT, you could do something we do on automotive key FOBs I've been involved in designing.  In this designs we detect the battery voltage as we place a known load on the battery.  We perform a LVD interrupt to immediately abort an attempt to do more higher power actions.    In your situation, you can wait for a minimal unloaded VDDD voltage or a loaded VDDD voltage before allowing further operation.

If the PSoC4 is hanging in the bootloader, there is little you can do to fix the issue if the bootloader is "hands-off".  If you're allowed to change the bootloader, you could apply the same basic techniques mentioned above.

The next step is to try to determine are the units stuck in the bootloader or application.

Once you determine where it hangs, you can modify your bench unit code (bootloader or application) by pushing GPIO output signals to know how far the code got before hanging.  (If you're familiar with the story of Handel and Gretel these are the breadcrumbs for debugging).

Keep us posted with any more details you can obtain.

Hopefully others might have better suggestions or their own experiences. 

Len
"Engineering is an Art. The Art of Compromise."

View solution in original post

5 Replies
Len_CONSULTRON
Level 9
1000 replies posted 750 replies posted 500 likes received
Level 9

DaGa,

Interesting issue!

I may not be the best expert on this issue but I'd like to start the discussion.

Can you replicate this issue with on-hand units?   If so, there might be ways to know where the CPU is hanging.  In the application or the bootloader.

If the PSoC4 is hanging in the application, there are some changes that might improve the issue.  Launching the WDT very early in the process BEFORE starting different components in particular the BLE component.

As each component is started (with the required clocks) more current is used.  A depleted battery with a high internal source resistance will drop the voltage to VDDD, VDDIO and VDDA.  This could be a problem causing the 'hang'.  Forcing the WDT early could at least provide multiple restarts of the code.

In addition to the early WDT, you could do something we do on automotive key FOBs I've been involved in designing.  In this designs we detect the battery voltage as we place a known load on the battery.  We perform a LVD interrupt to immediately abort an attempt to do more higher power actions.    In your situation, you can wait for a minimal unloaded VDDD voltage or a loaded VDDD voltage before allowing further operation.

If the PSoC4 is hanging in the bootloader, there is little you can do to fix the issue if the bootloader is "hands-off".  If you're allowed to change the bootloader, you could apply the same basic techniques mentioned above.

The next step is to try to determine are the units stuck in the bootloader or application.

Once you determine where it hangs, you can modify your bench unit code (bootloader or application) by pushing GPIO output signals to know how far the code got before hanging.  (If you're familiar with the story of Handel and Gretel these are the breadcrumbs for debugging).

Keep us posted with any more details you can obtain.

Hopefully others might have better suggestions or their own experiences. 

Len
"Engineering is an Art. The Art of Compromise."
DaGa_4378306
Level 4
10 replies posted 5 replies posted 5 questions asked
Level 4

Those are great suggestions.  I looked at my code, and I definitely can move the WDT earlier in the boot-up. But more importantly, I really think the idea of checking the battery voltage first before dropping into anything high power is a great idea!

So do you know if enabling the WDT in the the Clocks menu means that the Cypress device runs around setting up the WDT before my application code? 

 The hard part is recreating it, it happens on the dead-battery, and first application of charging - so even a little bit of charge, and I have to wait again. The LiPo itself has a cutoff circuit around the 3.0V min voltage.  

I can see lots of improvements for the bootloader as well -- but alas, that will have to wait for the next HW version...

BiBi_1928986
Level 7
250 replies posted 250 sign-ins 100 solutions authored
Level 7

Hello DaGa.

Yup.., painful debugging without access to pins.

Provided you can get the PSoC into a known state for a s/w update, you have access to LED GPIO (via software).  As Len mentioned, you could use GPIO's to indicate what state the code is in.  Blinking at various rates or intensities.

Is the charger IC inside the sealed unit?
If not, you have access to the PSoC 'charger' GPIO pin.  You could use the GPIO as a UART input or output (yes, disconnect pin from charger).  Implement a s/w UART if necessary.

Is the bootloader aware of the charger being plugged in?
I'm wondering about the under-lying problem.  Maybe bootloader is stuck in loop that wasn't accounted for.

I would not expect PSoC to be going through a reset sequence due to brownout.  A LiPo battery would still be around 3V when discharged.  Unless of course, it's being allowed to discharge below 3V (not a good thing).  Or, as Len hinted, a sudden heavy demand load could upset the apple cart.

Keep us informed.

0 Likes
DaGa_4378306
Level 4
10 replies posted 5 replies posted 5 questions asked
Level 4

So the bootloader is not aware of the charger GPIO (good stuff for next time around!). I will have to focus on the first steps in my application code. 

So does the Cypress part run around and configure all the HW blocks (per the "Clocks" default settings), and then still launch the application code? I don't have the WDT with hard reset enabled by default, but enable it in my application code. 

Dave

0 Likes
Len_CONSULTRON
Level 9
1000 replies posted 750 replies posted 500 likes received
Level 9

DaGa,

So does the Cypress part run around and configure all the HW blocks (per the "Clocks" default settings), and then still launch the application code?

Yes. However you as the designer can prevent many of the clocks from starting before launching the application.  This definitely applies to the user-defined clocks.  The system clocks such as IMO does not allow you to postpone starting the clock.   See the pic below and check out which clocks in the example are checked on "Start on Reset".

Len_CONSULTRON_0-1621181947422.png

The WDT is never started on reset.  The application (or bootloader) code must enable it.

Len
"Engineering is an Art. The Art of Compromise."