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.

CC3235SF: Latency fluctation problem on CC3235MODSF and no on CC3235MODS

Part Number: CC3235MODSF
Other Parts Discussed in Thread: CC3235MODS

Hello,

I'm currently working on a connected tool project, to communicate via wifi, the product is equipped with the CC3235MODS or CC3235MODSF wifi module depending on availability.
The embedded code on the two modules is the same, I simply switch the module model on code composer studio before compiling the code for each of the models.
The product itself works, whether equipped with a CC3235MODS or a CC3235MODSF, but I have noticed a latency problem on products using the CC3235MODSF module.

For example, when I connect a product using a CC3235MODS module to a wifi access point and then ping it, the latency is a few milliseconds with very little variation (from 3ms to 7ms with an average of 5ms). However, when I do the same thing with a product using a CC3235MODSF module, the latency is higher and very variable (from 50ms to over 300ms with an average of 200ms).
I've done this test with several products using each type of module, with the same Wi-Fi access point, then with different ones, in 2.4GHz and 5GHz, and the result is always the same. I've also changed the wifi module on a product that had the problem (changing the CC3235MODSF for a CC3235MODS) and the problem disappeared.

Do you have any idea what could be causing this problem, or any suggestions I could follow?

Thank you for your time.

  • By default the code on the SF runs from the internal XIP flash. the access to the Flash add few wait states that are not avoided when using the zero-wait-state SRAM on the S device. The difference in latency should not be so dramatic, but i'm not aware of other differences between the platform.

    You can try to moving all or part of your code to the SF SRAM and execute from there so it will run with no wait states.