TMS320F28379D: When configuring a GPIO pin for SCI Tx or Rx operation, is there a step I am overlooking?

Part Number: LAUNCHXL-F28379D

Tool/software:

I have a similar problem to the one described in the thread titled "LAUNCHXL-F28379D: SCI communication between two Launchxl-F28379d". I am building an application for a proprietary target board, but am debugging SCI communications using a LaunchXLF2839D board.

I have two versions of the firmware. One uses GPIO initialization that has been working for 2 years. A new team member has promoted a new architecture for GPIO pin initialization. Oddly the new pin initialization method works when SCIB is connected to GPIO137 and GPIO138 on the proprietary board. But it fails when I change the SCIB pin assignments to use GPIO18 and GPIO19 for testing on a LaunchXL board.

In the referenced thread, Allison Nguyen suggested trying the driverlib example project sci_ex1_loopback. I have imported that project to a local workspace. I then made a copy of that project folder, and edited the project folder name and the project files to alter the name of the new project to scib_ex1_loopback. So far so good.

The only source file that specifies the SCI port to use is board.h in the folder CPU1_RAM\syscfg. I made a copy of board.h, edited it to use SCIB and now I am unable to change the scib project to use the new board.h file. The original file board.h cannot be excluded from the build. I tried copying the new file into CPU1_RAM\syscfg replacing the original board.h. It seemed to work. But when I checked the contents of the source file, it had reverted to the original version which defines SCIA.

So what is the approved TI method of modifying a local copy of that driverlib project to use SCIB instead of SCIA?

Allison - thanks for assisting. The approach that DOES work on GPIO 18 and GPIO19 for SCIB on a LaunchXL board is the C200ware API, which you showed in your reply. The approach recommended by a consultant basically combines contents of those 5 API calls into a single function. The result SHOULD be the same. Contents of the GPIO registers after both methods are the same, as I listed in my original question. Yet the new approach fails to receive. So I am wondering what I may be overlooking in the process of configuring GPIO pins for SCI Tx and Rx that would explain the difference in behavior.

Hi Thomas,

To debug this, what I would do is run the program with two cases: (1) with the normal (working) GPIO setup functions and (2) with the combined function. In both cases, step over/into these functions and check the GPIO register values as you go/after in order to see if they result in the same/correct register settings. If they don't, that gives us a hint that the registers are not being written to properly. Let me know if you are able to do so. 

Best Regards,

Allison

Allison - I have both checked register contents as I step through the initialization, and checked GPIO register contents after the program is fully initialized. In both cases, register contents for GPIO18 and GPIO19 are the same in both the working version (which uses the C2000ware API) and the modified version of the program that uses the single function that combines operations performed by the five C2000ware functions. The register contents are shown in my original message.

I should mention that the same source of incoming data is used for both versions of the program. Protocol parameters are baud rate of 115200, 8 data bits, no parity, 1 stop bit. 

Hi Thomas,

Thanks for the clarification. Are you still able to scope out TX and see SCI activity? Can you confirm that internal loopback mode works ok still even with the combined API? Or are you saying even internal loopback is not functional? Can you confirm the GPAGMUX2 setting is also correct?

Best Regards,

Allison

Allison - The example program  sci_ex1_loopback, when modified to use SCIB, does work. But that is not surprising because AFAICT nothing in the program touches the GPIO pins to configure them for the SCI port after it has set the default "safe" GPIO pin map values for all pins early in initialization. I have not found a place in the technical reference manual where the bit settings in GPAMUX2 are translated onto the pin mux options, but the pinmap.h value for SCIRXDB is 0x00080602, and the bit pattern, which I gave in my first message is 0x10, which would be a 2, so it seems likely that is correct. It is also the same result when using either set of GPIO initialization code., both the one that works and the one that fails. I have not tried to adapt the single function GPIO init into the loopback program for the reason stated above, that loopback when executing does nothing with the GPIO ports. 

Hello,

Assuming your GPAGMUX2 and GPAMUX2 registers are both set up properly (as well as the other registers listed in your original post), I'm not sure why you'd be having issues with the SCI GPIOs to transmit and receive.

Our GPIO expert has been out of office but is returning next week so I can forward this over if needed. But let me try testing this out with the same register settings in the next day or so.

Best Regards,

Allison

Hello,

I just ran our SCI example 1 loopback project with GPIO 18 and GPIO19  (turned off loopback mode and physically jumped the pins) with no issues transmitting or receiving. Again, if your GPIO registers match, then the GPIOs should be configured properly. When you combine the configuration (the erroneous case) are you writing to the entire GPIO register/all bit fields at once? Or just writing to these specific GPIO bits? Are you writing these at a different time in the program than what is typical (before vs. after other peripheral init)?

Here are my GPIO register values using the example on 18 and 19

Best Regards,

Allison

Allison - Appreciate the time and work you are putting into this question. Re: your questions, 1) Before configuring those GPIO pins used in our application, we do the usual safe peripheral init steps. For GPIO pins, we first use the standard call as is used in example program sci_ex1_loopback, to configure all pins to safe settings as inputs. 2) When we set pin configuration settings for our application into each control register, we use an AND mask to clear bits for the pin being configured and preserve settings for all other pins on the control register, then OR in the changes only to the bits for the pin being configured on that pass. 

Hi Thomas,

Allison is currently out of office, so please expect some delay in her response.

Best Regards,

Delaney

Hi Thomas,

Apologies for the extended delay. Are you still facing this issue? I had a discussion with a colleague on this as well- it seems like you are switching between GPIO137/138 and GPIO18/19. Did you check if GPIO137/138 are reset to be default GPIOs? Can you double check those GPIO registers? And what are the SCI status registers in the non-working case? Do they indicate errors are seen?

Best Regards,

Allison

Allison - As I explained in my original message, GPIO18/19 are used when the target board is a LaunchXL-F28379D, because that is how SCIB is wired on that board. The ultimate target is a proprietary board developed by my client, which has wired SCIB to GPIO137/138. A compiler directive specifies which target board should be used for each build configuration. The GPIO for the proprietary board an be ignored, because the problem is demonstrable on a LaunchXL board

It has been a while since I last tested for this issue. In the interim, we are using the C2000ware initialization API. I could work up a test project adapted from an SCI example program ,with the new GPIO init function substituted into the example code to try to recreate the issue. If the issue is repeated there, I can send the program to you, but it would have to be via private message. I will have to find the time to develop that example code during slack time on my project, but slack time is a rare commodity, so it may take me a while. I can do that if you think that would be helpful. 

Hi Thomas,

Allison is currently out of office until after the holidays. Please expect a delay in response. Thank you for your patience.

Best Regards,

Aishwarya

Hi Thomas,

Thanks for sticking with this. Yes, if you are able to provide a cut-down of the project to isolate this section, please feel free to friend me on E2E and send via private message.

Best Regards,

Allison

Allison - Thanks very much. I will take you up on that offer. Creating an example application will have to be done as time allows, so please be patient. 

Hi Thomas, 

Sounds good. Yes, it would help for me to see what specifically is going on in your revised GPIO initialization. I'll await your friend request.

Best Regards,

Allison