• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 823 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.

IWR6843ISK: UART issue with IWR6843 VitalSign

Jonathan Ibera
Prodigy 200 points
Part Number: IWR6843ISK
Other Parts Discussed in Thread: AWR1642, IWR6843,

Starting with AWR1642, we changed the VitalSign on the algorithm side and was able to send the data output thru the UART to an external microcontroller succesfully. But we need to move to IWR6843ISK for regulatory compliance, so we started with the VitalSign codebase for IWR6843 that works well and copied the changes we did on the algorithm side, now the UART is throwing off (glitch) at random times and can't go more than 120s.  On the prior AWR1642, we can run for 30min on this UART with no issue.   

Note that I am using the mmwave SDK 3.1.1.2 and Industrial Toolbox 3.6.2 for IWR6843 ES1 chip. I am using the same SDK and Automotive Toolbox 2.5.0 for AWR1642 ES2 chip.

Here is the AWR1642 VitalSign profile we used (worked with no issue)

sensorStop
flushCfg
dfeDataOutputMode 1
channelCfg 1 1 0
adcCfg 2 1
adcbufCfg -1 0 0 1 0
profileCfg 0 77 7 6 57 0 0 70 1 100 2000 0 0 40
chirpCfg 0 0 0 0 0 0 0 1
frameCfg 0 0 2 0 10 1 0
lowPower 0 1
guiMonitor 0 0 0 0 1
collectChirp 0
vitalSignsCfg 0.4 1.1 256 320 1 0.1 0.05 300000 300000
motionDetection 1 20 0.04 0
sensorStart

Now, for the new IWR6843 we are testing (worked but no more than 120s and it throws off UART at random times)

sensorStop
flushCfg
dfeDataOutputMode 1
channelCfg 1 1 0
adcCfg 2 1
adcbufCfg -1 0 0 1 0
profileCfg 0 60.25 7 6 57 0 0 65 1 100 2000 0 0 40
chirpCfg 0 0 0 0 0 0 0 1
frameCfg 0 0 2 0 10 1 0
lowPower 0 1
guiMonitor 0 0 0 0 1
vitalSignsCfg 0.4 1.1 256 512 1 0.1 0.05 100000 300000
motionDetection 1 20 2.0 0
sensorStart

For reference, here are the TI provided profiles for AWR1642 and IWR6843 VitalSigns, respectively. 

%TI AWR1642

sensorStop
flushCfg
dfeDataOutputMode 1
channelCfg 15 3 0
adcCfg 2 1
adcbufCfg -1 0 0 1 0
profileCfg 0 77 7 6 57 0 0 70 1 200 4000 0 0 48
chirpCfg 0 0 0 0 0 0 0 1
frameCfg 0 0 2 0 50 1 0
lowPower 0 1
guiMonitor 0 0 0 0 1
calibDcRangeSig -1 0 0 0 0
vitalSignsCfg 0.3 0.9 256 512 4 0.1 0.05 100000 300000
motionDetection 1 20 2.0 0
sensorStart

%TI IWR6843

sensorStop

flushCfg
dfeDataOutputMode 1
channelCfg 15 3 0
adcCfg 2 1
adcbufCfg -1 0 0 1 0
profileCfg 0 60.25 7 6 57 0 0 65 1 200 4000 0 0 40
chirpCfg 0 0 0 0 0 0 0 1
frameCfg 0 0 2 0 50 1 0
lowPower 0 1
guiMonitor 0 0 0 0 1
calibDcRangeSig -1 0 0 0 0
vitalSignsCfg 0.3 0.9 256 512 4 0.1 0.05 100000 300000
motionDetection 1 20 2.0 0
sensorStart

Please critique our profiles for the before (AWR) and after (IWR) porting activity. Meanwhile, I will go debugging in the codebase if there is mistake made on porting activity.

Also, I saw the IWR6843 ES2 just came out, will this be more stable enough to solve this UART glitch issue?

Thanks so much guy for your work here. 

Jonathan Ibera

  • 0
    TI__Guru 50240 points

    Hi Jonathan,

    The UART issue you have described is more likely due to your computer system than the device. Have you tried running in high performance mode while also closing all other running applications?

    The only difference required for IWR6843 is that the start frequency should be 60.25 GHz.

    Cheers,

    Akash

  • 0 in reply to Akash Gondalia
    Prodigy 200 points

    But our ported code originally AWR1642 is working on UART for 30min with no issues. We ported it almost (algorithm) as close as possible to IWR6843 and UART is throwing off. I tried on 3 laptops and we see the same issue. It's possible our receiving application on the laptop could had timing issues.

    But using the original VitalSigns on both AWR and IWR and add our algorithm(maths) on it could cause IWR6843 to be different in output. Any other insight? 

    Jonathan