How can I reassign port pins to GPIO after they have been assigned to puart_tx and puart_rx?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

My application assigns puart_tx to GPIO_PIN_P0 and puart_rx to GPIO_PIN_P2 using puart_selectUartPads().  Both of these pins are connected to an external MCU.  To conserve power, this MCU needs to be turned off while its still attached to the port pins.  To avoid contention on these port pins when the MCU is off I need to be able to reassign these pins back to GPIO configured as inputs prior to turning the MCU off.

How can I reassign these port pins back to GPIO?  I'm assuming there is more too it than just simply calling gpio_configurePin() for each pin. The documentation is not clear at all on how pins get mapped back and forth between the UART and GPIO.

How do I disable the UART prior to reassigning its port pins to GPIO so that the reassignment does not trigger a glitch on puart_rx and thus make the UART think it received a byte when it did not?

Prior to turning the external MCU back on, I need to reassign the pins back to the UART and re-enable the UART.  How can I accomplish this?

1 Solution

Hi tedlogan

Sorry for the delayed reponse. Attached is the source code that toggles between UART and GPIO. We tried a firmware patch, but realised it does not solve the issue. So added the following two lines to fix the same. These are basically covering the HW pull up's.

      gpio_configurePin(puart_cfg->txpin / 16, puart_cfg->txpin % 16, 0x20, 0);

       gpio_configurePin(puart_cfg->rxpin / 16, puart_cfg->rxpin % 16, 0x400, 0);

Attached is the source code of working sample. To toggle between the same the SW1 is used.

HTH

vik86

alvin andrew997 mike.vogel

View solution in original post

0 Likes
21 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

I'm looking into this with the developers to determine the best way to accomplish the enabling and disabling of the PUART when the MCU sleeps, then wakes.

0 Likes
Anonymous
Not applicable

I simply want to know how to switch a port pin back and forth between being controlled by the periferal UART and controlled by GPIO.

Here is what I tried.

1) Mapped the port pins to the periferal UART using puart_selectUartPads() and intialized the UART as shown in the Broadcom documentation.

2) Verifed that the UART is driving the TX line and can transmit on the port pin.  The UART holds TX high when not transmitting.

3) Verifed that port pin can be changed to be controlled by GPIO by using gpio_configurePin() to configure it as an input and with a pull down.  The GPIO holds the pin low at this point.  The UART can not wiggle the pin if a transmit is attempted as would be expected because GPIO now has control of the port pin.

4) Tried to map the port pin back to being controlled by the UART using puart_selectUartPads().  This did not work the port pin is not being driven by the UART.  It is still low.

How do I make the UART control the port pin again instead of GPIO?

I also tried experimenting with bleprofile_PUARTTxOn() and bleprofile_PUARTTxOff() with no luck.  But it is not clear what these functions do because there is no documentation for them.

0 Likes

I spoke to the developers and gpio_configure() is the only way to reconfigure the pin back to a GPIO, but it appears you have that aspect under control.

They mentioned that you might want to configure the internal pull-up (or set the output) and then not use any of the PUART read/write routines. Then call puart_init again when ready to use the puart lines as a UART.

Let me know if this helps.  If not, I will ask for more guidance.

arvinds

0 Likes
Anonymous
Not applicable

I just tried calling puart_init() again when ready to have the uart contol the port pins again and this did not help.

Can you provide more guidance on how to accomplish this?

Does Broadcom have a users guide that shows all the register definitions for the chip? 

If so, this would be helpful for developers to use to bypass the API and control aspects of the chip like this in cases where the API documentation is lacking or in cases where the API does not provide the desired control.

0 Likes

Unfortunately, we do not provide any register definitions for any members of the BCM2073X family, so the API is what we have to work with.

I will check with the developers on the correct way to call  puart_init() when it's time to control the port pins.

More to follow

fdroberts2

0 Likes
Anonymous
Not applicable

Hello Ted,

I have worked on this issue and have a PUART APP that prints out to a Terminal window and also will print out what is typed in from a Terminal window that is connected to the PUART to the Debug Window.  The app after initializing the PUART to print out then turns P32/P33 into GPIO inputs which disables the printout from the PUART.  On a second button press it calls the same PUART_Init() function that is called originally in the App_Create().  What I see is that the Rx line(P33) is correctly getting re-initialized as I can see when I type in the Terminal window what I type gets printed out in the Debug Window(output from HCI_UART_TX)whereas the Tx line(P32) is not getting reconfigured correctly.  I have tried all sorts of combinations of configuring P32 with different GPIO settings and also clearing any potential prior interrupts.  Nothing has seemed to work to resolve this.  I am assuming Something is going on in the puart_selectUartPads() as to how the Tx line is being configured that we can not see and is not obvious.  I will check internally to come up with a resolution.

I have attached the Project I was working with...

Regards,

Frank

0 Likes

Hi tedlogan,

I was not able to reproduce your issue, I was able to toggle between gpio and puart. Could you kindly re confirm the issue, also by your explanation you mentioned "GPIO holds the pin low at this point." did you happen to verify it electrically on the scope and saw the issue ? Also correct my understanding. Initially the P32 and P33 are configured to be PUART pins are configured as default and I have some random numbers printed out on the console, on any event I toggle the P32 and P33 back to GPIO and see no uart messages the same on repeating toggle back to UART and it works as usual. Could you help me provide more information if your issue is not resolved.

thnx

vik86

alvin embeddedmasters mike.vogel andrew997

0 Likes
Anonymous
Not applicable

Hi vik86,

Yes, I verified it electrically by observing the signal level of PUART Tx line (P32).  As I mentioned earlier, I performed the following steps.

1) Configured P32 and P33 to PUART.  Verified that PUART is working by transmitting and receiving bytes.  Also observed Tx (P32) on a scope and verified that it was high when not transmitting and that it wiggles when transmitting.

2) Configured P32 and P33 to GPIO as inputs with pull downs.  Verified with a scope that Tx (P32) is now low (pulled down) and that transmitting bytes on the UART no longer wiggles P32.

3) Configured P32 and P33 to PUART.  Observed with a scope that Tx (P32) is still low (pulled down) (it should be driven high by the PUART at this point) and that transmitting bytes on the UART no longer wiggles P32.

Frank at embeddedmasters also reproduced the same behavior and sent source code on how to reproduce it earlier in this thread.  As Frank pointed out in this thread, the Rx line of PUART did get configured back to PUART correctly, but the Tx line did not.

Did you observe Tx on a scope as I did above?  If so, did you see Tx wiggle when you transmitted bytes on the PUART Tx after configuring P32 back to PUART from GPIO?

Ted

0 Likes

Hi Ted,

I've not got a chance to verify over the scope. Shall do and confirm you soon.

thnx

vik86

alvin embeddedmasters mike.vogel ahunter

Hi tedlogan

Here are my few observations,

As per embeddedmasters app that was attached on this thread, I could not find the GPIO related toggling , it had only PUART being toggled. The button press event had few UART /PUART logs, as per the block diagram below. I could not relate to your issue.

pastedImage_0.png

On reading and reproducing your issue, I could see that on the third toggle the PUART does not get initialized. Thus PUART_TX (from PUART to SerialConsole window -->Tx) is not being enabled, but the PUART_RX ( key input from console window--> PUART) works. Attached is a modified version of the embeddedmasters code. On button press I toggle between PUART and GPIO , but as I mentioned on the third toggle from GPIO--> PUART the PUART Tx is not getting initialized , working with arvinds on this issue, shall keep you posted on any updates. As per your requirement below is the block diagram

pastedImage_0.png

thnx

vik86

mike.vogel andrew997 alvin

0 Likes
Anonymous
Not applicable

Hi vik86

Thanks for the update and diagrams.  Your results are the same as what I observed.  I look forward to receiving a solution from Broadcom soon.

Best regards,

Ted

0 Likes

Hi tedlogan

Sorry for the delayed reponse. Attached is the source code that toggles between UART and GPIO. We tried a firmware patch, but realised it does not solve the issue. So added the following two lines to fix the same. These are basically covering the HW pull up's.

      gpio_configurePin(puart_cfg->txpin / 16, puart_cfg->txpin % 16, 0x20, 0);

       gpio_configurePin(puart_cfg->rxpin / 16, puart_cfg->rxpin % 16, 0x400, 0);

Attached is the source code of working sample. To toggle between the same the SW1 is used.

HTH

vik86

alvin andrew997 mike.vogel

0 Likes
Anonymous
Not applicable

wow, this is really helpful, THANKS vik86! I was trying to get this to work for a long time today before finding this thread and the last post from which finally made my code work.

Here's just a little further info on why this works from my research:

gpio_configurePin(PUART_TX_PIN / 16, PUART_TX_PIN % 16, 0x20, 0);

//changes bit 5, according to gpiodriver.h (SDK2.2.2) line 138:

//GPIO configuration bit 4:5,and 14 output enable control and muxing control

//ie 0x20=0b100000 = alternate function PUART

gpio_configurePin(PUART_RX_PIN / 16, PUART_RX_PIN % 16, GPIO_PULL_UP, 0); //GPIO_PULL_UP=0x0400

in another thread I started: ACLK output​ I got the answer from jakewtorres​ that

gpio_configurePin(32 /16, 32 % 16, GPIO_KS_OUTPUT_ENABLE, GPIO_PIN_OUTPUT_HIGH); // GPIO_KS_OUTPUT_ENABLE = 0x0010

aclk_configure(64000, ACLK0, LHL_CLK);

enables the alternative function "ACLK output" by setting bit 4. So I guess bits 4, 5 (and according to comments in gpiodriver.h) also bit 14 we can control muxing of the alternate functions of the pins. So I guess we could use this info to also try out some other alternate functions of the other pins! 🙂

Hope this helps someone else.

Appreciate the added support here foolography

0 Likes
asridharan
Employee
Employee
10 comments on KBA 5 comments on KBA First comment on KBA

tedlogan - Does your application's BLE_PROFILE_GPIO_CFG structure use GPIO_PIN_BUTTON? This you will notice is defined to 0 (for P0) and so will conflict with your use of it as PUART TX. Remove this and the corresponding GPIO_SETTINGS_BUTTON entry from this structure and then reinitialize PUART like in mwf_mmfae's message on Oct 15.

Anonymous
Not applicable

Hey arvinds,

  The testing that I did with the attached zip file uses P32 & P33 for the PUART and I still have the same issue.  I configured both P32 & P33 as Inputs and then later try to call the PUART_Init() function and only the Rx line gets re-initialized correctly the 2nd time the PUART_Init() function is called.

Regards,

Frank

0 Likes
Anonymous
Not applicable

Hi Arvinds,

My application does not use GPIO_PIN_BUTTON.  It has been removed from the BLE_PROFILE_GPIO_CFG structure.

Even though I mentioned that I'm using PUART on P0 and P2 in this thread, I actually intend to use them on those pins in my final hardware.  Currently I'm using PUART on P32 and P33 and doing my testing and development on the Broadcom development kit.  That is where I'm seeing the problem.

0 Likes
Anonymous
Not applicable

Is anyone at Broadcom working on a solution for this issue?

0 Likes

I will see if I can engage the factory on this one.

j.t arvinds

0 Likes

I wanted to check in and let you know that we are still escalating this internally with the Business Unit and trying to get some cycles from the development team to investigate.  Thanks for your patience.

alvin jorsini arvinds j.t andrew997

0 Likes
Anonymous
Not applicable

Thanks for the update.

0 Likes