CYW43907 MPU - Memory Protection Unit

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
NiMc_1688136
Level 5
Level 5
10 sign-ins 50 questions asked 10 solutions authored

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.

Observed behavior

"deviceType": "Sensor", "ype": "555555", "status": "Ok"

Expected behavior

"deviceType": "Sensor", "deviceID": "555555", "status": "Ok",

cJSON_AddItemToObject(deviceStatus, "deviceType", cJSON_CreateString("Sensor"));

cJSON_AddItemToObject(deviceStatus, "deviceId", cJSON_CreateString(getID_Str(generalStringBuffer)));

cJSON_AddItemToObject(deviceStatus, "statusCode", cJSON_CreateString(get_StatusStr()));

0 Likes
6 Replies
Zhengbao_Zhang
Moderator
Moderator
Moderator
250 sign-ins First comment on KBA 10 questions asked

Hello :

   We have MPU config in start_GCC.s , but didn't find memo code in the release .

Really strange,  Would you please compare string "ype" with "deviceID" before printing out to console ?

0 Likes

Yeah i was looking at start_GCC.s but i only saw init code which disables it. This doesn't help me in enabling or setting regions.

Regarding the string issue,

I could run a string check but would it even work? To run a strcmp or similar, i will still pass in a string literal or constant which would end up with the same error?

The weirder thing is, although this could be a coincidence, when you look at the bin file, the strings are stored sequentially like

d e v i c e T y p e  0x00 d e v i c e I d 0x00

It is almost like the address for "deviceID" was offset by 4.

0 Likes

strings are stored sequentially like

d e v i c e T y p e  0x00 d e v i c e I d 0x00

It is almost like the address for "deviceID" was offset by 4.

Yes,  How often does the error occur ?  I think we can print the address to see if it is due to the offset .

and you can print out all the sequence from "deviceType" to see if it is corrupted in the memory already .

0 Likes

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.

0 Likes

    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.

0 Likes

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.

0 Likes