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.

TMS320F28235: Can't enter the CPUtimer ISR routine until we change some declaration of variable from "float" to "Uint" on this fix point MCU

Part Number: TMS320F28235

Hi expert,

In brief, my customer put there APP code in one flash sector of F28235 and bootloader in another. In there APP code, CPUtimer ISR routine is used to feed an external watchdog chip. When they updated the code from serial bootloader, the CPUtimer ISR will not enter, but after they do below modification, it works well.

What they modified is:

In "DSP2823x_CpuTimers.h" they changed the "float" with "Uint" for "CPUFreqInMHz" and "PeriodInUSec".

I have no idea of how this is solved. I have the following questions here:

Q1: Will F28235 support "float" type data? (I think yes).

Q2: If "yes", why their modification solved the previous problem?

Q3: If "not", why this is no error given in project building process?

Q4: Could you help me explain the root cause for this or how could I narrow my search for the root cause? My customer is afraid of any potential risks behind this.

Thanks!

  • Hi Sheldon,

    F28235 does not support Floating Point Unit, only F28335 does, it is mentioned in the data sheet. Hence if you are developing the code on F28235 then do not use "Float".

    I am not sure why compiler is not giving an error. I will assign it to compiler team to better assist you with that.

    Regards,
    Nirav
  • Hi Sheldon,

    Although there is no hardware support for float operations, the compiler does provide software versions of float operations which is why the compiler doesn't give an error.

    As to why it was failing, I think I need more information. What particular values were they using for the variables? Did they find which calculation involving the variables was giving bad results?

    Whitney
  • Hi Whitney,

    They have below values input. Please help me check if there are any risks.

    BTW, this problem happens only when the application is updated through bootloader. If they erase and program both the application and bootloader code by emulator, the ISR not enter problem will no happen. So if this have no risks, I will check other parts.

    Thanks!

  • Like I said, the compiler can handle the floats. The code size will of course be bigger since it requires extra library calls to handle them in software, but it's not a risk.

    I am curious why it isn't working with the bootloader though. Where do the CpuTimer1.PeriodInUSec and CpuTimer1.CPUFreqInMHz variables get used in the code? Only in PRD register initialization or elsewhere?

    If you connect to the device after the bootloader runs (without GEL to avoid the reset on connect), can you capture the CPU Timer registers and see how they are different from the register values used when loaded from the emulator?

    Whitney
  • Hi Whitney,

    As far as I know, these two variables are only used to build the PRD in the code.

    Do you mean that we can connect the emulator to the device  even with the program running? Could you tell me how to make this?

    At the time being, I have asked them to print the values of these registers, for they didn't have a serial port to do print work. I let them use LED on device to indicate digits. If we can use a emulator, it will be a good news!

    Thanks!

  • Yes, as long as your hardware allows it, you should be able to connect the emulator and check the state of things. You launch a debug session like you normally would, but before you connect to the device, go to Tools->GEL Files and right click on the GEL file to remove it. Then you should be able to connect without resetting the device, meaning you should be able to look at the registers as they were configured by the boot-loaded program. You can also load symbols for your project and start stepping through the code if needed.

    Whitney

  • Hi Whitney,
    It works, also we need to uncheck "Connect to the target on debugger startup" in debug configurations to make this happen. Thanks for your help, I will further investigate on this issue.