This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3100: Hardfault in Host Driver

Part Number: CC3100
Other Parts Discussed in Thread: UNIFLASH, CC3200

Our company uses CC3100 chips for a long time in home security systems. Platform is STM32 with cooperative OS. Since 2017, for many reasons, we didn't update neither Host driver nor chip, no service pack applied. Our Host driver is version 1.0.1.11. Last month some client devices reported a hardfault on the same place: simplelink\source\driver.c Line 1143:
case CMD_RESP_CLASS:
NWP_IF_READ_CHECK(g_pCB->FD, g_pCB->FunctionParams.pTxRxDescBuff, _SL_PROTOCOL_ALIGN_SIZE(g_pCB->FunctionParams.pCmdCtrl->RxDescLen));
At the same time, that devices have an error returned by sl_WlanPolicySet(SL_POLICY_CONNECTION, SL_CONNECTION_POLICY(0, 0, 0, 0, 0), NULL, 0) function call, which means flash error, afaik.
Under NWP_IF_READ_CHECK macros I have and HAL_SPI_Receive_DMA(&wifi_spi, buf, len) and non-blocking waiting until SPI_RxCpltCallback arrive.
Can you help with this?
Hardfault is very rare, I couldn't reproduce it on my table.
I see a suspicious macros _SL_PROTOCOL_ALIGN_SIZE in the string above, in some circumstances it can cause a buffer overflow on reading.
Can a Host Driver upgrade fix this? Is it neceaasry to apply a chip servicepack too?

  • Hi,

    Hard fault are not easy to debug and may be caused by stack overflow or other memory overrun faults.

    You can read through the internet for possible reasons. See this one for example https://interrupt.memfault.com/blog/cortex-m-hardfault-debug

    As for your specific case, failing on NWP_IF_READ_CHECK() means that probably something went bad with the synchronization with the NWP. May be host interface integrity but also NWP crashing for some reason.

    To double check this, you can fetch NWP log to make sure if something happens. Do you get any asynchronous event that indicates a fatal error?

    Shlomi

  • Hi Shlomi,

    Thank you for your answer. I am not sure about async event, because if it came right before HF, my soft could not log it. And stack is enough, HF report shows SP is on the 1/3 of current task's stack. I guess if NWP crashes, it should not cause host driver to hardfault.
    1) What about _SL_PROTOCOL_ALIGN_SIZE macros mentioned above? It increases size, and if a buffer doesn't have extra 4 bytes, NWP_IF_READ_CHECK can overflow it. I didn't dig too deep in host driver code to find the output buffer for NWP_IF_READ_CHECK call. Is this call always safe?
    2) What can be the reason for a flash error returned by sl_WlanPolicySet? In my casee I read current settings by sl_WlanPolicyGet, and if they are incorrest, I call sl_WlanPolicySet and get an error. Error disappeared after flash formatting. How to avoid flash corruption and extend flash lifetime?
    3) You mentioned NWP log, how to grab it?

    BR
    Michael

  • Hi,

    The _SL_PROTOCOL_ALIGN_SIZE macro should be OK (or at least I couldn't find any issue across few years). Basically, the buffer used is allocated by the TX side when a command is sent to the device, waiting for the command response. In the command response, the code you mentioned is invoked.

    Are you saying that the servicepack is old or you never flashed it with a servicepack? if you don't have a servicepack at all (running from ROM), it is not recommended.

    To enable NWP, you can follow the procedure on chapter 20 in the NWP UG here https://www.ti.com/lit/ug/swru455m/swru455m.pdf?ts=1713276158721&ref_url=https%253A%252F%252Fwww.google.com%252F

    You can also find in this forum many posts that discuss it.

    Regards,

    Shlomi

  • Hi,


    Yes, no any service packs was applied to our CC3100 chips. This is OK? And SDK v1.3.0 with HostDriver v1.0.1.11 are the latest? No need to upgrade?

    BR
    Michael

  • No servicepack is really not recommended as there were endless fixes in the NWP/MAC/PHY.

    Luckily, the service pack should work even with older driver like the v1.0.1.11 that you are using.

    I would have update the service pack.

    Shlomi

  • Currently, problems arize only in new CC3100 chips, which, I guess, already contain all NWP/MAC/PHY fixes that you mentioned. How to check chip version to decide whether it needs a service pack or not? And are there new versions of host driver for CC3100? is v1.0.1.11 the latest one?
    Michael

  • What CC3100 chipset are you using? IC or module? what is the silk label on the chip says?

    I am asking since only the module contains a serial flash where the servicepack is stored. If you are using an IC, for sure you do not have a servicepack.

    The best way to check the version is either by calling the right API from the application or capturing an NWP log from the device.

    v1.0.1.11 is not the latest. The latest is v1.0.1.14.

    Shlomi

  • It is a chip, the labels are:

    CC3100R1

    983 ZRL4 G4

    All external components are as written in the manual, including external flash W25Q16.

    And where to download host driver v1.0.1.14 ?

  • So if you did not update the servicepack using Uniflash, it is highly recommended to do so.

    You can find the latest under https://www.ti.com/tool/CC3200SDK

    Shlomi

  • Thank you. But that host driver is for CC3200, is it suitable for CC3100?

    And which service pack for CC3100 have I choose among these: www.ti.com/.../CC3100SDK

  • yes, the host driver is the same.

    just take the latest SP, v1.0.1.15.

  • Hello Shlomi,

    I can apply a service pack to any CC3100R chip, old or new?

    Michael

  • Hi Michael,

    Latest ServicePack is compatible with all CC3100R devices. But is it not compatible with pre-production devices like XC3100HZ (PG 1.32).

    Jan

  • Thank you!