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.

TMS320F28335: what influnces to MCU system or peripherals of changing RANDWAIT and PAGEWAIT Configuration of FBANKWAIT Register

Part Number: TMS320F28335

Dear my friends,

I am using TMS320F28335 as the main controller in EV driver,  I have a problem when  I am doing the CAN bus off test ,when I recovery the bus line , sometimes(nearly 20%), ODB give the diagnostics command through CAN bus to controller, there is no any reply from 28335, but the other part run normally, and I  finally found that when I change RANDWAIT and PAGEWAIT  of FBANKWAIT Register  from 5(default)  to 10, the CAN communication recovery normal,

so I want to how to explain this, anybody knows if I change the RANDWAIT and PAGEWAIT  more bigger, what happened in MCU internal(system and other peripheral)? just change Flash wait cycle? 

  • Flash wait-states should have no bearing on CAN operation, as long as you meet the "Minimum Required Flash/OTP Wait-States at Different Frequencies" as shown in the datasheet. How do you ensure that the eCAN module is indeed out of the bus-off condition? It appears you are attempting communication too soon. Perhaps that explains why more waitstates for the flash helps. Can you try the same code running off RAM? Do you use 32-bit read/writes while accessing the CAN registers?

  • Hi Hareesh, thanks for your kindly reply, and could you tell me  in what situation that I need to change  RANDWAIT and PAGEWAIT ? and how would I evaluate the code  execution time or efficiency if I change RANDWAIT and PAGEWAIT more, for example, from 5 to 10? thanks. 

  • Stephen,

                The wait-states needed for a given SYSCLKOUT frequency is given in Table 5-65 on page 96 of the datasheet (SPRS439N). The device has been tested to operate reliably at these wait-states. There is no need to increase the wait-states (and hence reduce the throughput of the device). If a peripheral is not working the way it should, you should identify the root-cause of the issue rather than increasing the wait-state. To assess the impact of increased wait-states , you could toggle a GPIO pin at the beginning and end of an event or use the CCS profiler. Again, the root-cause of your issue is something else.

  • Dear Hareesh J,

    Thank you so much for your kindly reply, I really appreciate your help! thanks.

  • Could you please close this thread (Mark it as "Answered") if you have no more questions?