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.

TMS320C5545: EBSR and GPIO PINMUX selection at run time?

Part Number: TMS320C5545

Team,

The C5545 TRM - SPRUH087H does mention the below:

12.2.2 Signal Descriptions
The device supports up to 26 signals on TMS320C5535/34/33/32 and up to 20 signals on TMS320C5545,
GPIO[31:27], GPIO[20:0], simultaneously. All GPIO pins are muxed with other signals and have an
optional internal pull-down resistor. The mux is controlled in the External Bus Selection Register (EBSR)
located at port address 1C00h. The routing of the signals takes place on the next CPU clock cycle.
Before
modifying the values of EBSR, you must first clock gated all affected peripherals via the Peripheral Clock
Gating Control Register (PCGCR1 and PCGCR2) at addresses 1C02h and 1C03h.
The EBSR can be modified only once after boot process is complete. Continuously switching the EBSR is not supported.
Pulldowns are disabled or enabled by the Pulldown Inhibit Register (1C17h, 1C18h and

1C19h). These GPIO are muxed with other signals. For more information on the package pinout and
muxing of each GPIO signal, see the device-specific data manual.


-Can there be exception to this since the GPIO pin mux is quite restrictive?
-Can you confirm that the PINMUX settings can be done only once after boot?
It seems that some BOOSTERPACK test code does not follow this recommendation (some more info will be provided soon).

Thanks in advance,

ANthony

 

  • Antony,

    I can confirm that in C5545 BoosterPack Software Release, led_test.c, run_led_test(), the mode is set to 6, to 2 and to 1.

    In order to set the 3 leds on GP[16], GP[17] and GP[28] of the Boosterpack board, the mode has to change, because no mode exists where those 3 pins are GPIO.

    Regards,

    Marten
  • Hi Anthony,

    We urge customers to set the EBSR pinmux once at the beginning of their application code, and to leave it set that way throughout the application. The reason is that after the EBSR register is modified, asynchronous logic is used to propagates the memory-mapped register bits to various decoders and muxes around the chip. Before the logic settles, unintended glitches and intermediate states can occur. This adds to risk at the board and chip level. Imagine a chip select going low, allowing garbage into some memory. Or worse, imagine if a pin-muxed GPIO is used to activate a motor that might cause bodily harm when activated unintentionally by changing the EBSR pin muxing. In this scenario, proper board-level isolation should be implemented to mitigate such risk.

    The device does not support dynamic changes of the EBSR register configuration, which means there could be cases that the desired configuration would not work. We did not test all the thousands of possible combinations of changing the EBSR on the fly. Thus, there might be a case that breaks something. This register affects a whole bunch of muxes around several peripherals and their I/Os. Further, the timing of the mux changes could be affected by device conditions (temperature, supply levels, etc.) and also could cause some undefined state, causing glitches that could cycle back into a peripheral or external device. Given the severity of the change and I/O connections on a board, it would seem prudent that user is not going to be rerouting things on the fly. Just set it once and continue. All the peripherals must be idled before the change and then reset after the change to avoid glitches causing issues.

    That said, to access all the features on the C5545 Boosterpack (like LED3 and DSP_SDCD) changing the EBSR mux mode is required.
    However, for the above reasons, it is our recommendation to set PPMODE to MODE1, MODE2, or MODE6 depending on the application, and leave it there.
    On other EVMs, we have resorted to I2C IO expanders to have more GPIOs available.

    Hope this helps,
    Mark