- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Does Cypress team has any comment about this?
Is there anyone reproducing this issue on any platform/SDK with the provided code?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Same failure is seen w/ SDK 3.7.0-3.
And still no any response from Cypress ......
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So glad that someone notices this thread ......
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
BCM4390 and BCM43362
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It seems OTA not working on platforms with internal flash.
(ex STM32 MCU )
Hi Cypress team please do something.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Sam.
It has been a long time....^^
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I will attempt to escalate the issue again within the core engineering team.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm sorry that I don't have BCM94343WWCD1_EVB......
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I tested on the Avnet and BCM94343WWCD1_EVB modules. Anything that uses the STM32F4xx MCU will be broken with the current code.
-Rob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could you let me know if the Wiced SDK v5.0 or later version has already rectified this SPI bug?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for confirming robjderr
I will relay these finding to the core SW team that asked for validation on a Cypress board.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I can confirm it works now with robjderr's change.
The code also tells the original code was never get tested at all.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
From source code SDK 3.7.0-3 should not solved this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.