TMS320F28388D: How to switch between CPU1 and CM in runtime for TMS320F28388D controlller ?

Hi Shreyas,

Let me get back to you with a response on this next week.

Best Regards,

Delaney

Hi Delaney, since you mentioned getting back to us this week, I’m just checking in to see if you have an update. Looking forward to your response!

Hi Jayashree,

Please allow me another 2 days to have an update. It has been the weekend in the US as well as a US holiday today, so I haven't been in office to look into your question yet,

Best Regards,

Delaney

Hi Jayashree,

Apologies for the delay. 

Shreyas Kumawat said:

During runtime, is it possible to shift application control/logic between CPU1 and the CM core (e.g., start on CPU1, then run portions on CM, and switch back)?

The CM core and CPU1 core can run completely simultaneously once the CM core is booted. Any code running from the main() on the CM project starts executing simultaneous to the CPU1 program execution. Note that for the UART peripheral, this is owned by the CM core and CPU1 does not have access to the UART registers, so only the CM core would be able to do UART operations. The UART pins are configured in the GPIO registers, which only CPU1 has access to, so that has to be done by CPU1 during initialization. See the device block diagram here to understand which cores have access to which resources.

Shreyas Kumawat said:

Can the CM core communicate back to CPU1 (send data/events), i.e., is communication bidirectional between CPU1 and CM?

Yes, you can use the message RAMs to communicate in each direction:

• CPU-to-CM MSGRAM
• CM-to-CPU MSGRAM

Shreyas Kumawat said:

If yes, what is the recommended mechanism to do this (IPC, shared RAM/message RAM, interrupts, etc.) and any pointers/examples would be really helpful

It depends on the nature of your data, if you just simply need to interrupt one core from a different core you can just use IPC flags. If you want to send a stream of data, you can use the MSGRAMs along with IPC for synchronization. I would suggest looking at the two CM IPC examples in [C2000ware install]/driverlib/f2838x/examples/c28x_cm/ipc/ folder.

Please upvote this response if it answers your question and feel free to ask any additional questions you may have.

Best Regards,

Delaney

Thanks for the clarification regarding CPU1–CM simultaneous execution and MSGRAM communication.
My question is specifically about GPIO42 (UARTA_TX / USB0_DM) and GPIO43 (UARTA_RX / USB0_DP), where:

USB0_DM / USB0_DP are owned by CPU1

UARTA_TX / UARTA_RX are owned by the CM core


Question 1
During initialization, CPU1 configures GPIO42 and GPIO43 mux to UART, enables the required clock, and then CM core starts using them for UART communication.
After some runtime (for example, after 1 hour), can CPU1 reconfigure the same GPIO42 and GPIO43 back to USB (USB0_DM / USB0_DP) and start using USB again?
In short, is dynamic runtime switching of these pins between UART (CM) and USB (CPU1) supported and safe, not just during initialization?


Question 2
While CM core is using GPIO42 and GPIO43 as UART:
If a user connects a USB cable, will the USB module (CPU1 side) still detect/receive any USB interrupt or connection event, or will USB be completely inactive because the pins are muxed to UART?


Main Requirement
My goal is to use GPIO42 and GPIO43 for both UART and USB and switch their function dynamically during runtime, not only at startup.
Is this approach recommended and reliable, or could it cause stability/resource conflicts?

Hi Jayashree,

1. I see, for question 1 I don't know of any issues but let me loop in the GPIO expert to comment.
2. If there are no GPIOs configured for the USB, it can still run, it just won't have any signals brought out to the outside world. From the peripheral point of view, it is running the same as normal, the peripheral has no knowledge of if GPIOs are connected or not. I'm not very aware of the USB interrupt events, but anything that relies on a signal coming from externally would not be able to trigger an interrupt if there are no GPIOs muxed to the USB.
3. I will also defer to the GPIO expert on this. However, to add, I would recommend holding both modules in reset when doing the mux switch to make sure the peripherals don't get into an unexpected state.

Best Regards,

Delaney

Hi Jayashree,

Jayashree Patil said:

My goal is to use GPIO42 and GPIO43 for both UART and USB and switch their function dynamically during runtime, not only at startup.
Is this approach recommended and reliable, or could it cause stability/resource conflicts?

It is fine to do this as long as you are properly putting the USB/UART module in reset when you switch the pinmux.

Regards,

Peter