Turning to the community and cypherbridge for insight on yet another hard fault -- forum searches reveal no existing information on this topic.
We've observed a handful of hard-to-pinpoint hard faults, and pieced together some data from stack dumps.
Our faults seem to be coming from a memcpy call within tls_get_next_record
Since the source is not available, we can only work with the assembly. The link register and program counter points these instructions at the time of fault
tls_get_next_record: ... +152 bl 0x804e580 <memcpy> ldrh.w r9, [sp, #12] (LR) memcpy: ... +266 ldrb.w r4, [r1], #1 (PC) cmp r1, r2 strb.w r4, [r3, #1]! bne.n 0x804e68a <memcpy+266> |
For all the occurrences, the devices were on WICED 3.1.2, with no particular timing pattern, or any pattern for that matter. We've recently migrated to WICED 3.5.2, and haven't observed anything since, but it's too early to draw any conclusions. Is this a known issue, and is anybody else experiencing similar faults?
The SDK changelogs does mention a couple of TLS fixes and improvements, but nothing that addresses this issue in particular.
