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.

UART module receive issue after GetMode boot to flash mode ?

Other Parts Discussed in Thread: LAUNCHXL-F28027F

I've the launchpad LAUNCHXL-F28027F and I am using the example project lab (proj_lab02b).

I added a serial communication to the program with configuration and I am using pins 29 and 28 as the TX and RX.

When I boot in the emulation mode (enabling TRST) to use the in circuit debugger, the serial serial communication works fine without any errors.

When I use the GetMode boot to flash mode (disabling TRST pin and raising GPIO34 and GPIO37) the program starts normally and the serial transmit TX works fine but the serial receive RX doesn't work nor the MCU receive any data until I made a restart to the MCU (manually forcing that using the restart push button in the launchpad circuit ).

  • Hello,

    So during normal debug operation, the SCI RX is working properly, but in standalone the RX channel never appears to work? 

    Can you add some debug capability in the configuration code? Maybe toggle a separate GPIO at certain checkpoints around both the GPIO configuration as well as the SCI RX configuration.

    Another option is to create a target configuration file where you do not us a GEL file. You can add an infinite loop at the beginning of your code. You can then power the board up using your standalone process, then connect to the device and continue debugging.

    Thanks,
    Mark

  • Thanks Mark for your reply, but I didn't get your point.

    My problem that when I use GetMode boot to flash mode, the serial RX doesn't work until I made a restart to the MCU, meanwhile

    everything else in the program works fine even the serial TX also works !  It's just the RX doesn't receive any in its buffer until I made 

    a restart to the MCU (using the bush button connected to RST pin) ?! 

  • My point is that you need to dig in and see what might be causing the issue. I suggested adding debug checkpoints in the code as a way of tracing what is actually occurring during runtime. Without more information on what the device is doing, it is rather difficult to provide useful information.

    I will pull in our boot experts and see if they might chime in with some thoughts.

    -Mark