I am currently developing some firmware for a battery charger that uses the EFM8BB31F64I-C-5QFN32 and the EFM8 USB Type-C Library (ver 1.1.1) which is available as part of the 4.1.7 SDK.
We have had reasonable success utilising the library and are at the stage where we are making final modifications ready for production.
Unfortunately in our latest design iteration we have hit a problem. One of our requirements was to have a serial interface, and we wanted to keep the option of utilising the built in bootloader available through UART0. I have been able to get the UART and PD library working independently but seem to be able to get them to work alongside each other. And believe the problem is due to changes in the pin allocation made to accommodate the UART0 pins.
It is my understanding that the SPI module is used by the library to enable comms on the USB CC lines. And has its signals rerouted from the pins assigned by crossbar (physically not connected to anything) to the pins that are physically connected to these lines. Looking at the pin configuration I could see that the SPI module should be allocated pins P0.3, P0.5 and P0.6.
To accompany the UART0 interface I shifted the pins to P0.2, P0.3 and P0.6 (since UART0 required P0.4 and P0.5).
I believe the problem is that the MISO signal that is originally assigned to P0.5. Looking at the registers I can see that the other SPI signals (Clk and MOSI) are routed via the configurable logic units, and confirmed that the library still works when only the clk pin is changes (P0.3 changed to P0.2) but as soon as I try and change P0.5 to P0.3 the library stops working and looking at the PD messages using an analyser it looks as though incomplete responses are being sent back by the charger/library during PD negotiations (backing up the theory the problem is caused by the MISO pin being changed).
Due to not being able to see anything in the register settings that shows how the MISO signal (P0.5) is being redirected, I'm assuming that the library must be manually referring to the pin directly. Which would explain why it is unable to cope with the pin assignment changing for that specific signal.
Could you please confirm if this is the case and if there is a way of getting both UART0 and the PD library to work alongside one another.
Can you show us the exact code changes you made in order to set the new SPI pins?
Sorry I don't have a simple code snippet to share, but I will try and share the relevant register values I changed.
The new SPI pins were allocated by making changes to the crossbar registers. Configured as part of the appcfg_Configure_GPIOs function.
The SKIP0 register was changed to clear the bits associated P0.2 and P0.4.
XBR0 |= XBR0_CP0E__ENABLED | XBR0_CP1E__ENABLED | XBR0_SPI0E__ENABLED;
was changed to
XBR0 |= XBR0_CP0E__ENABLED | XBR0_CP1E__ENABLED | XBR0_SPI0E__ENABLED | XBR0_URT0E__ENABLED;
To enable the UART0 peripheral and have the pins allocated by the crossbar.
Going by the reference manual this should then mean that the pins are allocated as detailed in my previous post.
I also took care to make sure the new pins were configured in the same way.
I hope this helps.
I'm assuming from your response, that the EFM8 USB Type-C Library should handle having the SPI pins moved, if done correctly.
Can you please confirm if this is the case.
I looked through the internal source code of the USB_PD library, and found that the CLU3 manually sets one of its inputs to P0.5, expecting the MISO signal. Unfortunately, there is no way to properly reconfigure the CLU3 outside of the library. In order to get the UART bootloader and the USB_PD library to work together would be to modify the bootloader to use UART1 instead of UART0.