SDK-3.6.3 / SDK-3.7.0 wiced_framework_set_boot() doesn't work

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.
JeGu_2199941
Level 5
Level 5
25 likes received 10 likes received 10 likes given

Test procedure :

     step 1. extract the attached file to apps/ folder

     step 1. build with make target : snip.app1-BCM94343W_AVN

     step 2. build with make target : snip.app0-BCM94343W_AVN download download_apps run

In SDK 3.5.2 it works as expected :

     app0

     wiced_framework_set_boot(DCT_APP1_INDEX, WICED_FRAMEWORK_LOAD_ONCE) = 0

     app1

     wiced_framework_set_boot(DCT_APP0_INDEX, WICED_FRAMEWORK_LOAD_ONCE) = 0

     app0

     wiced_framework_set_boot(DCT_APP1_INDEX, WICED_FRAMEWORK_LOAD_ONCE) = 0

     app1

     (repeat)

In SDK 3.6.3 & 3.7.0 I can see only the first boot :

     app0

     wiced_framework_set_boot(DCT_APP1_INDEX, WICED_FRAMEWORK_LOAD_ONCE) = 0

     (stop here)

Remark:

1. In SDK 3.5.2, file wiced_waf_common.c is modified as this post : Possible 3.5.2 bug in wiced_framework_set_boot()

2. In SDK 3.7.0, file platform/BCM94343W_AVN/platform.c is modified as this post : Re: SDK 3.7.0 BLE doesn't work

3. In all 3 SDK version stock snip.ota_fr works out of box with snip.scan

0 Likes
1 Solution

I finally found the problem!  The platform_spi_init function has an optimization where it checks to see if the spi has already been initilaized

WICED/platform/MCU/STM32F4xx/peripherals/platform_spi.c line 180

    if (spi_current_config[spi_number].bits == config->bits &&

            spi_current_config[spi_number].cs.port == config->chip_select->port &&

            spi_current_config[spi_number].cs.pin_number == config->chip_select->pin_number &&

            spi_current_config[spi_number].mode == config->mode &&

            spi_current_config[spi_number].speed == config->speed &&

            spi_current_config[spi_number].spi == spi->port &&

            spi_current_config[spi_number].spi_ready == WICED_TRUE)

        return PLATFORM_SUCCESS;

What happens is the configuration is stored in spi_current_config structure and is compared to the config parameter and returns success if it's the same.  When the system resets the values in api_current_config aren't reset and the system assumes that the spi bus has already been configured and doesn't properly enable the spi bus.  So the system halts when the spi bus is accessed because it's not enabled.

The solution I came up with is to check that the SPI register has been enabled.  The datasheet says the default value of the CR1 register is 0x0000 after a reboot.

    if (spi_current_config[spi_number].bits == config->bits &&

            spi_current_config[spi_number].cs.port == config->chip_select->port &&

            spi_current_config[spi_number].cs.pin_number == config->chip_select->pin_number &&

            spi_current_config[spi_number].mode == config->mode &&

            spi_current_config[spi_number].speed == config->speed &&

            spi_current_config[spi_number].spi == spi->port &&

            spi_current_config[spi_number].spi_ready == WICED_TRUE &&

            spi->port->CR1 != 0x0000)

        return PLATFORM_SUCCESS;

This completely fixed the issue for me.

-Rob

View solution in original post

34 Replies
JeGu_2199941
Level 5
Level 5
25 likes received 10 likes received 10 likes given

Does Cypress team has any comment about this?

Is there anyone reproducing this issue on any platform/SDK with the provided code?

0 Likes

Same failure is seen w/ SDK 3.7.0-3.

And still no any response from Cypress ......

0 Likes

Hi,

I hit the same issue on BCM94343W with sdk-3.7.0.

Any update from Cypress team?

After wiced_framework_set_boot() call, the device cannot boot any more.

The only way to boot is re-download the image.

mwf_mmfae

0 Likes
Anonymous
Not applicable

I have tested the same with both SDKs 3.6.2 and 3.7.0 and found the same. As mentioned in

Possible 3.5.2 bug in wiced_framework_set_boot()

we have implemented the same in these two SDKs and still there is an issue. We will check internally for the cause.

0 Likes

Hi rash,

Any chance to post the fix ASAP?

I'm waiting for the OTA fix because I'm going to send devices to some customers

soon. Since current SDK has memory leak, it definitely needs image update.

0 Likes

So glad that someone notices this thread ......

0 Likes
Anonymous
Not applicable

It's broken since 3.6.3 and it's MUST HAVE for most of product so I think the team is pushing customer projects away.

It's confusing that the team seems not taking responsibility about MUST HAVE function broken for a long time.

I don't believe any projects relying on ota (not ota2, it's not available for non-Cypress MCU platform) can be MP on SDK after 3.6.3.

0 Likes
Anonymous
Not applicable

Hi 

  -   OTA issues, it has been long time from SDK 1.2.xx

      I think that user have to select way or give up OTA function

  -  OTA issues goes with OS and IP stack

- General testing information.

   - FreeRTOS + LWIP : it has been worked well with any SDK release.

   - ThreadX+NetX       : it has been a problem with chunk error or sometimes it worked.

- SDK 3.7.0 testing information

   - FreeRTOS + LWIP : OK

   - ThreadX+NetX       : Not OK (Chunk error and other stuffs )

   OTA testing image size : 319K   ( ThreaX image is 3% bigger than FreeRTOS )

- Please test with FreeRTOS +LWIP

  -With FreeRTOS  : some of API does not work like ThreadX.

TKS

0 Likes

manulsan wrote:

- SDK 3.7.0 testing information

   - FreeRTOS + LWIP : OK

Which platform are you testing?

I'm pretty sure it does not work on BCM94343W.

0 Likes
Anonymous
Not applicable

Hi

BCM4390 and BCM43362

0 Likes
Anonymous
Not applicable

It seems OTA not working on platforms with internal flash.

(ex STM32 MCU )

Hi Cypress team please do something.

0 Likes
Anonymous
Not applicable

Hi Sam.

It has been a long time....^^

0 Likes

I will attempt to escalate the issue again within the core engineering team.

xavier@candyhouse​ / manulsan​ / axel.lin​ / sam.lin

I am receiving some pushback from the team related to the use of an Avnet board which is not directly supported within the SDK.

Would any of you have access to a a BCM94343WWCD1_EVB Cypress evaluation board? I'm hoping that you do and can easily reproduce the same steps using it.  I now have a case open with the team, so once I have this step complete, I can ask them to start looking into the issue.

0 Likes

I'm sorry that I don't have BCM94343WWCD1_EVB......

0 Likes

I don't have BCM94343WWCD1_EVB board.

I think you should ask someone in your team to verify if the issue is reproducable on your standard board. It only takes a few minutes which is much faster than asking users to get a BCM94343WWCD1 EVB board.

I have access to the BCM94343WWCD1_EVB and ran the test application and experience the same issue.

snip.app1-BCM94343WWCD1

snip.app0-BCM94343WWCD1 download download_apps run

I'm also experiencing the same issue with our OTA process.  The device won't reboot after calling wiced_framework_set_boot.  The customers are forced to pull the power on the device to get it working again. 

I track the issue down to WCIED/platform/MCU/STM32F4xx/peripherals/platform_spi.c line 418 called from load_program in the bootloader...

    /* Wait until the transmit buffer is empty */

    while ( SPI_I2S_GetFlagStatus( spi->port, SPI_I2S_FLAG_TXE ) == RESET )

    {

    }

I hope that helps...

I really wish Cypress would spend the time trying to help their customers instead of pushing back that the platform isn't supported.

-Rob

Call stack from the debugger

dbg_watchdog_irq() at platform_watchdog.c:252 0x80005a6
<signal handler called>() at 0xfffffff9
SPI_I2S_GetFlagStatus() at stm32f4xx_spi.c:1,176 0x80026fc
spi_transfer() at platform_spi.c:418 0x800218a
platform_spi_transfer() at platform_spi.c:360 0x80025f6
wiced_spi_transfer() at wiced_platform_common.c:336 0x8002170
sflash_platform_send_recv() at spi_flash_wiced.c:34 0x80020b2
generic_sflash_command() at spi_flash.c:405 0x8001f24
sflash_read_ID() at spi_flash.c:23 0x8001f76
init_sflash() at spi_flash.c:350 0x8002066

wiced_apps_read() at wiced_apps_common.c:441 0x8001314

The system gets to the SPI_I2S_GetFlagStatus function and loops there until the watchdog resets the system.

-Rob

I finally found the problem!  The platform_spi_init function has an optimization where it checks to see if the spi has already been initilaized

WICED/platform/MCU/STM32F4xx/peripherals/platform_spi.c line 180

    if (spi_current_config[spi_number].bits == config->bits &&

            spi_current_config[spi_number].cs.port == config->chip_select->port &&

            spi_current_config[spi_number].cs.pin_number == config->chip_select->pin_number &&

            spi_current_config[spi_number].mode == config->mode &&

            spi_current_config[spi_number].speed == config->speed &&

            spi_current_config[spi_number].spi == spi->port &&

            spi_current_config[spi_number].spi_ready == WICED_TRUE)

        return PLATFORM_SUCCESS;

What happens is the configuration is stored in spi_current_config structure and is compared to the config parameter and returns success if it's the same.  When the system resets the values in api_current_config aren't reset and the system assumes that the spi bus has already been configured and doesn't properly enable the spi bus.  So the system halts when the spi bus is accessed because it's not enabled.

The solution I came up with is to check that the SPI register has been enabled.  The datasheet says the default value of the CR1 register is 0x0000 after a reboot.

    if (spi_current_config[spi_number].bits == config->bits &&

            spi_current_config[spi_number].cs.port == config->chip_select->port &&

            spi_current_config[spi_number].cs.pin_number == config->chip_select->pin_number &&

            spi_current_config[spi_number].mode == config->mode &&

            spi_current_config[spi_number].speed == config->speed &&

            spi_current_config[spi_number].spi == spi->port &&

            spi_current_config[spi_number].spi_ready == WICED_TRUE &&

            spi->port->CR1 != 0x0000)

        return PLATFORM_SUCCESS;

This completely fixed the issue for me.

-Rob

Anonymous
Not applicable

Oh that make sense since this piece of code doesn't appear in SDK 3.5.2

Now I believe the core team didn't ever test OTA on SDK 3.6.3 and SK 3.7.0 release.

Cypress team now please confirm the issue and do necessary fix & merge in next SDK release since you have been supported by robjderr.

robjderr

Just to confirm.  OTA is now working for you on SDK 3.7.0-3 using the Avnet IoT 4343W based Starter kit?  Thanks for reporting these findings back to the group.

I'm hoping some of the others can confirm the fix as well.  I will report to our team.

0 Likes

I tested on the Avnet and BCM94343WWCD1_EVB modules.  Anything that uses the STM32F4xx MCU will be broken with the current code.

-Rob

Note that the developers just confirmed that this was resolved in SDK 3.7.0-3, which is available here on the community: WICED SDK 3.7.0-3 .7z Source files

0 Likes

robjderr wrote:

    if (spi_current_config[spi_number].bits == config->bits &&

            spi_current_config[spi_number].cs.port == config->chip_select->port &&

            spi_current_config[spi_number].cs.pin_number == config->chip_select->pin_number &&

            spi_current_config[spi_number].mode == config->mode &&

            spi_current_config[spi_number].speed == config->speed &&

            spi_current_config[spi_number].spi == spi->port &&

            spi_current_config[spi_number].spi_ready == WICED_TRUE &&

            spi->port->CR1 != 0x0000)

        return PLATFORM_SUCCESS;

This completely fixed the issue for me.

-Rob

mwf_mmfae​,

Just to remind you this change is also not included in sdk-4.0.1.

I don't mean to blame anyone, just want to tell you some users may hit the same issue even with latest SDK.

Could you let me know if the Wiced SDK v5.0 or later version has already rectified this SPI bug?

0 Likes

Thanks for confirming robjderr

I will relay these finding to the core SW team that asked for validation on a Cypress board.

0 Likes

I can confirm it works now with robjderr's change.

The code also tells the original code was never get tested at all.

0 Likes

mwf_mmfae

This is not the first time cypress team changes the code without testing it at all.

Another example is add checking for the return value of dct_read with inverse logic.

Yet another example is removing a "break" cause tftp failure.

Seriously, You need a full test before releasing the SDK.

Anonymous
Not applicable

Hi Sir,

We're doing embedded system and we work on our own PCB design.

And I think this issue is not related to standard EVB or not.

May I asked one question:

Did your core team test OTA with SDK 3.6.3 and 3.7.0 on BCM94343WWCD1_EVB when released ?

If you did, you should be able to reproduce it since there are many reports on it.

If didn't, why do you ask us to test it first ?

To summary it to be clear:

1. the issue happens on switching app to FR partition (or OTA i believe) in bootloader due to this call:

wiced_framework_set_boot()

2. the ota_fr itself as app also has issue due to it also contain this call

Your code team can easily access BCM94343WWCD1_EVB and spends less than half hour to tell us what's your findings.

From your response it seems months of reports never got into your core team sight.

The platform is sinking.

Tested with SDK-4.0.0.
HW : Avnet 4343W Starter Kit

Platform file : Avnet platform file for SDK-3.7.0

Result : same failure as original post

Note that the developers just confirmed that this was resolved in SDK 3.7.0-3, which is available here on the community: WICED SDK 3.7.0-3 .7z Source files

0 Likes
Anonymous
Not applicable

From source  code SDK 3.7.0-3 should not solved this.

I confirmed that the error with wiced_framework_set_boot() noted here in this thread: Possible 3.5.2 bug in wiced_framework_set_boot() was fixed in SDK-3.7.0-3

The error related to the work around robjderr​ provided above is being looked into.  Sorry for the confusion.

0 Likes

I feel most of the time are in passing messages with your developers.

If your developers can directly involved in the discussion here, it would be easier to fix issues.

Actually, it can save a lot of time for your team.

0 Likes