• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 31 subscribers
  • Views 431 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

FDC2214EVM: Serial communication stops working after a while

Naichia Yang
Prodigy 60 points
Part Number: FDC2214EVM


Hi. We are having problems on maintaining communication with FDC2214EVM. Here's the background info:

- After we got the board, we did a sanity check on a PC, updated the firmware, re-checked sanity, then we connected the board to the target host which runs Linux. The Linux box runs a shell script to read/write the registers on the board. The script's communication protocol follows information seen in this thread (.../support/sensors/f/1023/t/805053), which we've also verified by capturing the USB data while running EVM GUI.

- The script is able to read the desired registers successfully, but every once in a while it could time out on receiving data (but a retry or a few tries later it could succeed), or it could end up getting an I/O error on the serial port (/dev/ttyACMx). Once it gets an I/O error, it can no longer talk to the board; the green LED on the board is turned OFF; any attempt to reset the serial port or the USB device is to no avail. The only way to recover is to unplug and replug the USB.

- The timing of the reads seems to have some impact if we run the script in a loop and read the same channel (e.g., Ch_2, MSB+LSB), with or without inserting a small delay (0.2 or 0.5 sec) in the loop. Strangely, it's more likely to get into the I/O error condition when there IS a delay between reads.

Questions:

1. What could have caused the state of the board to change (green LED is OFF)? and what exactly is the state of the board in that case?

2. Why would the timing of reads affect it, and how come giving it more time makes it worse?

3. As the above thread indicates, the communication protocol with the current firmware is no longer according to the FAQ thread that you often refer to (.../support/sensors/f/1023/t/295036). While we can figure out commands like "?" (who am I) and for reading/writing registers, there are obviously others we don't know. For example, what's the purpose of the initial packet "4C 03 01 00 00 0F" and the expected response (is it "FF 00 4C"? and what does it mean?). Can you provide a complete protocol description for the current firmware?

Thanks.

Naichia

  • 0
    TI__Mastermind 18545 points

    Hello Naichia, 

    These are good questions and I will need some time to give you the best answer for them. I will need to do some testing and look into what the firmware could be doing for these cases. To help with that, are you doing anything other than reading a channel in the loop where you add the delay or is it just the channel reading? 

    Thank you, 

  • 0 in reply to Justin Beigel
    Prodigy 60 points

    Hi, Justin. Thanks for getting back to me.

    No. Within the loop it's simply reading the MSB and then the LSB of the given channel (Ch_2), nothing else.

    Naichia

  • 0 in reply to Naichia Yang
    TI__Mastermind 18545 points

    Hello Naichia, 

    Thank you. I should have an answer back to you by the end of this week. 

    Best Regards, 

  • 0 in reply to Justin Beigel
    Prodigy 60 points

    Hi, Justin. Thanks for following up on this.

    Just an additional info ... It appears the condition has no real relationship to timing. We could execute the reads manually (reading any register from the shell script each time it executes) at arbitrary intervals (a few or many seconds in between ... you know, it's manual), and it could get into this situation after a while. Most of the time it's between 20 to 40 reads, but could be fewer or more.

    Please let me know if you need any other information.

    Naichia

  • 0 in reply to Naichia Yang
    TI__Mastermind 18545 points

    Hello Naichia, 

    I've had some issues with my python environment  and haven't been able to test everything or recreate the issue yet. In the meantime, I can address the LED question you have. 

    If the board encountered an error that the firmware can't handle then it would go into an error state and turn off the green LED. The only way to reset from a state like this would be to power cycle the board. 

    Best Regards, 

  • 0 in reply to Justin Beigel
    Prodigy 60 points

    Thanks for the explanation, Justin. That's what we suspected and it makes sense.

    Naichia

  • 0 in reply to Justin Beigel
    Prodigy 60 points

    Hi, Justin,

    Any update or more information you can provide? or do you need more information from us to help you investigate?

    In the meantime, can you provide answer to my other question about the communication protocol, including the function of the packet "4c 03 01 00 00 0f" (which the EVM GUI sends to the board as soon as it's started), and the meaning of the response "ff 00 4c", and the meaning of other responses if different (we've seen some different responses when sending this packet multiple times).

    Here are a few other questions (or maybe they are clues to the original problem we saw):

    1. The spec says the board enters the SLEEP mode upon power-up (SNOSCZ5A –JUNE 2015–REVISED JUNE 2015, Section 9.4.1). However, that's not the case we observed. EVM GUI shows bit 13 of the CONFIG register is 0. Where's the discrepancy coming from? Caveat: Since EVM GUI always sends that "4c 03 01 00 00 0f" packet in the beginning, I don't know if it alters the board's state.

    2. The same section also recommends that the FDC be configured while in SLEEP mode. My question is: what happens if the board is configured while NOT in Sleep mode? Any adverse effect?

    3. The channel 2 readings, when successfully returned, very often contains the error bit Amplitude Warning. I'm guessing this is due to inadequate configuration. My question is: can this have any effect (randomly or cumulatively) on the operation of the board and may have caused the problem we're seeing?

    I'd appreciate if you will be able to move forward with your investigation and/or answer some of these questions.

    Thanks.

    Naichia

  • 0 in reply to Naichia Yang
    TI__Mastermind 18545 points

    Hello Naichia, 

    I don't have a definite answer for you on the EVM GUI packet question but it is pointing to just an identification command for the EVM. I still need to confirm this but wanted to let you know for now. As for your new questions:

    1. The firmware on the MSP portion of the EVM puts the device in active mode during initialization. That is why the EVM GUI shows this bit being set to 0 on startup. 
    2. If you config while not in Sleep mode, then there is no guarantee that the device will always accept the register change. There is also a potential to mess with a current reading that the device is taking, especially if you change any of the settings around the sensor. 
    3. The amplitude error warning is due to inadequate configuration. The sensor oscillation should be between 1.2-1.8V and this error flag is a warning that the oscillation is not in the range. This should not have any effect on the communication error you are having but it would be worth fixing either way. 

    Best Regards, 

  • 0 in reply to Justin Beigel
    Prodigy 60 points

    Thanks for the information, Justin. We'll double check our configuration. I assume you're still trying to recreate the problem, while also getting more information about the communication protocol. Please let me know how it goes, and if you need more information from us. Thanks.

    Naichia

  • 0 in reply to Naichia Yang
    TI__Mastermind 18545 points

    Hello Naichia, 

    That is correct, so far I have had no luck recreating the issue. I will keep you updated as I get more information. 

    Best Regards,