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.

PGA450-Q1: Possible Bug in PGA450-Q1 firmware v2.4

Part Number: PGA450-Q1
Other Parts Discussed in Thread: TIDA-00151

Hi everyone, 
   I am currently working with a PGA450Q1EVM-S ultrasonic sensor and I am analyzing its firmware. In particular, I download the TIDA-00151 UART & LIN Demo Firmware for PGA450-Q1 v2.4 (Rev. D) from this link ( http://www.ti.com/lit/zip/tidcab3 ) directly from the PGA450-Q1 page ( http://www.ti.com/product/PGA450-Q1/toolssoftware ).

First of all, is this firmware the one uploaded on my sensor, which I bought a month ago? 
If yes, while I was reading the code, I noticed something strange in the pga450_main.c file:

functions command1 and command5 call, at lines 175 and 358 respectively, the burst_cap_comp function which is declared at line 536.  From the burst_cap_comp declaration it seems that it expects a comm input which represents the communication interface (0 means UART communication, 1 means LIN). When a look at the burst_cap_comp call in command1 and command5, they call it passing the range variable as input. I think that this could be a bug; infact, if I trigger a command 1 in short mode using an UART communication (command 0x00 0x55 0x11 0x01 0x00), in the command1  function, the range variable is equal to 1 and when it calls the burst_cap_comp function with 1 as input, the latter uses range as comm thus triggering case 1 in the initial switch, which sets the function as if it was called using a LIN communication.

Am I missing something? 

Thanks in advance

GD 

  • Hi GD,

    Yes, the pre-installed firmware on the PGA450Q1EVM-S is identical to the downloadable demo firmware for the UART interface. The downloadable demo firmware also includes the ability to enable LIN communication if required.

    Thank you for identifying this bug! We will correct and release the updated version of the firmware soon.
    When you issue a short range command 1 {0x00 0x55 0x11 0x01 0x00}, the 8051 receives a UART interrupt to execute command1(0); in the pga450_isrs.c file. Command1 is based in pga450_main.c, which passes in the value comm=0. The initial switch case statement sets range to read UART_data[3], which is a values of "0x01" in this example. In the following if-else conditional, range==1, so the short range settings are applied. Finally, the burst_cap_comp function is should be passed the comm variable to indicate if the burst_cap_comp function should refer to UART or LIN since the burst_cap_comp function once again pulls the range data.

    Apply the following fix to the command1 and command5 functions in pga450_main.c:
    burst_cap_comp(comm); // old code --> burst_cap_comp(range); // Burst,Capture,Compare

    Alternatively, you can pass in the range parameter to burst_cap_comp function to eliminate the redundant switch case statement.

    Once again, thanks for catching this bug!
  • Hi Akeem,

    You are welcome.

    I would like to add that this bug affects both DEVRAM and OPT source code.
    I agree with with your bugfix of changing the burst_cap_comp calling from the range variable to the comm one. In addition, just to give other users a quick workaround, if you trigger command1 / command5 in long   mode, the firmware behaves as expected: in fact, when the burst_cap_comp function is called with comm = 2, the initial switch does not perform anything and range remains assigned as it was in the command1 / command5 function since it is a global variable.

    I'm glad to help

    GD