This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Timing changing from debug mode to release mode in M3

In my project based on smartfusion, I am using UART of cortex M3 to communicate with PC. The problem i am facing is that when Cortex M3 program is running in debug mode i receive correct data in PC, but when i put the same in release mode timings go haywire and it does not work.

Please suggest what may be missing. Please Ask any additional input if required.

I will really appreciate early reply.

Thanks

  • What do you mean with debug mode and release mode? Compilation options? Or switching between simulator or real hardware? Running with or without JTAG adapter? Something else?

    You say the communication timing go haywire. But you don't tell how.
    - Wrong baudrate?
    - Received characters lost?
    - Transmitted characters lost?
    - Characters sent too close after each other?
    - ...

    Have you used a scope to look at the signals?
    What do they look like?
    What did you expect them to look like?

  • Failure to enable clocks, the debugger may enable system features it uses.

    Dump internal register states (peripherals, clocks, etc), in the debug vs release modes.

    Failure to wait on status register bits.

    Perhaps you can add diagnostic output you can use to understand the flow and function of your code absent a debug pod being attached.

  • we are using uart communication from smart fusion evaluation board card to PC using virtual COM port on evaluation board itself using CP2102 IC.
    UART0 is initiliazed with baud rate of 1500000. I am trying to send 4 bytes one by one by calling uart_polled_tx function four times with a delay of some minimum duration. This code works fine when i am running in debug mode, but in release mode i.e. when the code is loaded in the envm of smartfusion , then the data through UART is missed out or its incorrect. The error is only in sending data from smartfusion to PC, but PC to smartfusion data transfer works fine with same baud rate.

  • we are using uart communication from smart fusion evaluation board card to PC using virtual COM port on evaluation board itself using CP2102 IC.
    UART0 is initiliazed with baud rate of 1500000. I am trying to send 4 bytes one by one by calling uart_polled_tx function four times with a delay of some minimum duration in between. This code works fine when i am running in debug mode, but in release mode i.e. when the code is loaded in the envm of smartfusion , then the data through UART is missed out or its incorrect. The error is only in sending data from smartfusion to PC, but PC to smartfusion data transfer works fine with same baud rate.

    In release mode we are running without JTAG adapter and in debug mode we are running with JTAG adapter. In debug mode programm is running on PC, we can have breakpoints to stop the program at required step but in release mode we cant do this.

  • How can debug mode be both "running on PC" and "running with JTAG"?

    You connect a JTAG adapter to virtual hardware in the simulator???

    Next thing - the simulator doesn't emulate all hardware fully. How are you making sure your UART is ready to accept more serial data? If you don't have code pacing the transfer, then you are likely to lose characters. The simulator will probably not care about the baudrate when figuring out how fast a UART can swallow new data.

  • If I can translate this correctly. It works in the SIMULATOR, and doesn't work in REALITY.

    Get a scope or logic analyzer and test your assumptions about actual speeds and bit/symbol timing of the output.

    Use a standard baud rate like 115200, instead of some made up one.

    Make sure your code programs all the registers and clocks properly. Assume that reality is a more harsh interpretation of the Reference Manual, double check all the register/bit settings, and THINK about how you can TEST each of the steps in the initialization sequence so you can figure out where it's breaking. Perhaps you can use the JTAG debugger to step through the code, checking the output/clock states at each step?