Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
Is there any example code on working with the MPU in the CYW43907? The datasheet documentation mentions 8 different MPU regions.
I have found a weird scenario where string literals used to generate JSON messages became corrupt after many hours of running without error. I am not sure if they are being overwritten in SRAM or what. With normal MCU's constants could not be written to directly but when executing from SRAM with the CYW43907, everything is accessible. The device built correct JSON strings after a power cycle.
This particular issue was raised by our customer on one device out of ~14600 devices. As previously mentioned, the system was running fine, reporting messages as normal for days and then all of a sudden the this key in the json message changed and required a power cycle to return to normal condition.
That is really a particular issue, would you please ask customer to add protection if they found the print string is wrong , do a cJSON_Delete and recreate the object to send data again. better to print more logs to find if an error return happened in the long run test.
But the JSON string is dynamically generated & deleted every 60 seconds. If data at the SRAM address of the string literals is corrupted or for what ever reason there is a 4 byte offset in retrieving the data, it won't matter if i call cJSON_Delete (which is already called).
This reason is why I started the thread asking about the MMU.