TMS320F280049: SCI Autobaud Issue

Apologies for the delay in response, I was out sick.

The lspclkHz input of the SCI_setConfig() function is intended to be the actual LSPCLK clock value. Additionally, the SCI_setConfig() function shouldn't actually be relevant after you use the SCI_lockAutobaud() function:

• SCI_setConfig()
  • 
• SCI_lockAutobaud()
  • 

Debug questions:

• What are the contents of the SCIHBAUD and SCILBAUD registers before the autobaud lock? Do adjustments of SCI_setConfig() correctly show in these registers?
• What is the intended final baud rate?

Regards,
Jason Osborn

SCIHBAUD = 0x0

SCILBAUD = 0x5D

These are the values of SCIHBAUD and SCILBAUD registers before the autobaud lock when we pass the following arguments to the SCI_setConfig function 

SCI_setConfig(XXXXX_SCI_BASE, DEVICE_LSPCLK_FREQ, 230400, 
              (SCI_CONFIG_WLEN_8 | SCI_CONFIG_STOP_ONE | SCI_CONFIG_PAR_NONE));

where 

DEVICE_LSPCLK_FREQ = 25MHz

The intended final baud rate is 230400.

Hm. With those parameters, the value of SCILBAUD should be 0x0D, I believe. For a baud rate of 230400, SCILBAUD=0x5D would require DEVICE_LSPCLK_FREQ to be just under 7x the given value.

Questions

• Are the values you provided when using a multiplier on LSPCLK_FREQ like you described above, or not?
• What are the contents of the SCIHBAUD and SCILBAUD registers after the full autobaud process?

Regards,
Jason Osborn

1) You are correct, my bad. SCILBAUD=0x5D happens when

  SCI_setConfig(XXXXX_SCI_BASE, DEVICE_LSPCLK_FREQ * 7, 230400, 
              (SCI_CONFIG_WLEN_8 | SCI_CONFIG_STOP_ONE | SCI_CONFIG_PAR_NONE));

and it is SCILBAUD=0x0C when
  

  SCI_setConfig(XXXXX_SCI_BASE, DEVICE_LSPCLK_FREQ, 230400, 
              (SCI_CONFIG_WLEN_8 | SCI_CONFIG_STOP_ONE | SCI_CONFIG_PAR_NONE));

2) SCIHBAUD = 0x00 and SCILBAUD = 0x0C after the full autobaud process is successful. And this just happens when using

DEVICE_LSPCLK_FREQ * 7 in th SCI_setConfig.

If the result is 0x0C, the autobaud process resulted in a baud rate of 223214, which is just under the intended target, which is correct. However, you said the autobaud does not work in your original post- am I misunderstanding something?

Regards,
Jason Osborn

Hi Jason, 

As we stated in the post, autobaud is only working when we have either 

DEVICE_LSPCLK_FREQ * 7 in th SCI_setConfig

or 

debugger connected and running. 

To clarify, while adding/removing multiplier in SCI_setConfig() is changing the values for SCILBAUD, there is no difference when we try to send a message after SCI_setConfig(). The baudrate of the message is always 1.66Mbps, shown by the scope capture. 

The “real” baudrate will only be corrected when autobaud works, which requires us to put a multiplier in SCI_setConfig(), confirmed by the scope capture. Without the multiplier, it will be as if autobaud did not see any messages thus will not send out anything. 

I see- so when there is no multiplier, the value of SCILBAUD is correct, but the actual output is not right- and additionally, the autobaud does not function. Alright, thank you for the clarification.

I need a bit more time to look through the information you provided and get back to you. In the meantime, I want to clarify one of my previous questions- When the autobaud fails, what are the contents of SCILBAUD and SCIHBAUD?

Regards,
Jason Osborn

The Autobaud function doesn't have a timeout, so the way we know it fails it is because it got stuck in the Autobaud function. The other microcontroller sending the 0x0A in a infinite loop also gets stuck as the TMS320F280049 never successfully gets the Autobaud to finish.

Alberto,

I'd misunderstood you before, then. My apologies Thank you for your clarification and patience in explaining this issue.

I'm going to discuss this issue further internally- nothing I'm seeing should result in this issue. This is very odd. I have some thoughts, but nothing that quite makes sense, given the full context of the problem.

To clarify my current thought process:

• Section 23.13.3 Autobaud-Detect Sequence of the device TRM has a note on the autobaud performance:
  • 
  • Given the desired baud rate of 230k, this is relevant.
  • However, if this is the issue, then the two fixes- adjustment of SCI_setConfig() and simply connecting to JTAG- should not have any impact whatsoever- this is why I haven't explicitly mentioned it before.
    
    
• Adjustment of the LSPCLK value in SCI_setConfig() should not impact the autobaud whatsoever. Any values in the baud registers are overwritten at the start of the baud SCI_lockAutobaud() function. The fact that adjustment of the LSPCLK value is impacting is very strange, and makes me think something else is going on.
  
  
• It's worth stating that the autobaud process described in Figure 4-5. Overview of SCI Boot Function of the device TRM (intended for use in SCI Boot, but also explicitly describing an autobaud use case) disables the SCI FIFOs and interrupts prior to using the autobaud. Since this is only mentioned in the context of the SCI Boot Mode, and you can successfully execute autobaud in some cases, this is not particularly likely to be relevant, hence why I did not mention it before now.

As I said, I'll continue discussing this internally to try and determine a root cause based on our discussions so far. If there is any further information you're able to provide, please let me know. Depending on what we're able to determine, the following information may end up being useful:

• Any relevant HW differences between the old board and new board mentioned in your prev. thread on this topic, such as wiring differences, device changes, pinout changes, etc.
• Which SCI peripheral (-A or -B) is being used
• What IO is being assigned for each SCI pin
• JTAG configuration details
• Device boot mode

Regards,
Jason Osborn

Hi Jason, 

sorry for the late rely. Our software engineer is out this week but I will answer the ones I know. 

Q: Any relevant HW differences between the old board and new board mentioned in your prev. thread on this topic, such as wiring differences, device changes, pinout changes, etc.
A: We don't think there is any significant HW differences especially related to SCI and that's why we are a bit confused. We are using the same external oscillator and we are using the same pinout for SCI. The main changes for the DSP was that we swap some of the ADC pins around but I don't image that would impact the SCI. The layout did change a bit but the SCI connections to the other microcontroller are just 2 traces with nothing in between, same as before. 

Q: Which SCI peripheral (-A or -B) is being used
A: This I'm not super sure.

Q: What IO is being assigned for each SCI pin
A: We are using GPIO22 VFBSW for SCITX and GPIO13 SCIRX

Q: JTAG configuration details
A: I'm not sure about the software config. Hardware wise we are using the 14pin JTAG and with the same setup as the datasheet example.

Q: Device boot mode
A: We have pull up and GPIO 24 and 32, thus boot mode = flash. 

Based on the pin choice, you're using SCIB.

Note that IO22 has the following pinout note in the datasheet:

If the SCI pins are unchanged from the working version, this is unlikely to be the root cause, but it's definitely worth checking.

Thank you for all the information. I'm still discussing internally and hope to get back to you soon with a more probable cause.

Regards,
Jason Osborn

Hi Jason, want to follow up to see if you have found anything related to this issue? 

Hi Jason, 

Want to check in to see if there is any update.

Sorry for the delay in response, I was out sick for quite a while, and missed updating you because of that.

Based on the information provided, I've been unable to find any distinct root cause- Nothing indicated should be causing these issues, assuming that you've also been checking my debug suggestions, such as the note on GPIO22 in my last post.

I would like to follow up on the other questions I've asked, then I have more and debug suggestions:

1. I mentioned in a prev. post that FIFO and SCI interrupts are disabled in our autobaud example. Has this been verified to be true in your case?
   
   
2. I mentioned in a prev. post that auto-baud locking at a lower speed and then increasing the speed could be attempted. Has this been tried?
   
   
3. Did the pinout of the signals next to the SCI and JTAG signals change? From what to what, if so?
   
   
4. Do you have more than one unit of this system? If so, please:
   1. Verify the issue is present on both units
   2. If the issue is only present on one unit, please perform an A/B swap test to determine if the issue follows the MCU or the HW
      
      
5. Is the prev. MCU pin-to-pin compatible with the new implementation? If so, please perform A/B swap test with the old HW + old MCU and the new HW + new MCU. This would ideally tell us if it is the MCU or the HW that is the source of the problem.
   
   
6. If the problem can be verified to be the new MCU using either/both of the above tests, my next debug suggestion is this:
   1. Set up an unused GPIO to trigger an interrupt. If none are available, use the TDI pin, since the debugger must be disconnected for the problem to occur, so it is available in this instance.
   2. Configure a second unused GPIO for SCI-A TX at a pre-set baud rate. (GPIO37/TDO/SCIA_TX is what I would use here)
   3. Set up the new interrupt to write the values of the SCILBAUD, SCIHBAUD, and SCIRXBUF of SCI-B to the output pin.
      1. Alternatively, if you're familiar with DMA, the input pin could be used to trigger a DMA read of the SCI-B registers and a write to the SCI-A Tx buffer.
   4. Run the system to the fail state (i.e. failing to reach autobaud lock)
   5. Drive the input pin to trigger the interrupt and watch the output.
   6. This will let you determine the state of the SCILBAUD, SCIHBAUD, and SCIRXBUF registers in the fail state, despite having no debugger present.
   7. Report back with the values of these registers, as well as any other SCI or IO registers you feel may be helpful.

I'm sorry again that I've been unable to determine the source of this issue.

Regards,
Jason Osborn

Hi. 

Thank you for the reply. Sorry our software team hasn’t had the bandwidth so far to help out checking some of these yet still. Will get back to you once we try some of these things you mentioned.