• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 405 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.

Original question:

IWR6843ISK: FCC Certification using mmWave SDK in CW mode...

IWR6843ISK: FCC Certification using mmWave SDK in CW mode continued...

Thomas Grounds
Prodigy 90 points
Part Number: IWR6843ISK

The previous thread is locked, and I'm not sure why.  I wasn't done yet.

I may have code that is working for the CW output, however I haven't been able to confirm that.  I'd like to know if there is a way to determine if the BSS can return a status to verify that.

If we give the software a full setup via the CLI interface, we get the following.

configuration with the tracker settings runs fine
Debug: Sending rlRfSetLdoBypassConfig with 0 0 0
============ Heap Memory Stats ============
Size Used Free DPCUsed
System Heap(TCMB) 98304 31360 66944 3072
L3 786176 491520 294656
localRam(TCMB) 4096 512 3584
============ Heap Memory Stats ============
Size Used Free DPCUsed
System Heap(L2) 32768 16008 16760 0
L3 786176 32768 753408
localRam(L2) 50176 23848 26328
localRam(L1) 16384 5872 10512
dfeDataOutputMode=a0000000
Starting Sensor (issuing MMWave_start)
[C674X_0] Data Path Stopped (last frame processing done)
DSS Task Stack Usage (Note: Task Stack Usage) ==========
initTask 4096 764 3332
Task Name Size Used Free
ObjDet DPM 4096 2308 1788
HWI Stack (same as System Stack) Usage ============
Size Used Free
2048 748 1300
[Cortex_R4_0] Data Path Stopped (last frame processing done)
============================================
MSS Task Stack Usage (Note: Task Stack Usage) ==========
Task Name Size Used Free
Init 2048 1752 296
Mmwave Control 3072 2368 704
ObjDet DPM 8192 4760 3432
HWI Stack (same as System Stack) Usage ============
Size Used Free
2048 808 1240
Sensor has been stopped: startCount: 1 stopCount 1

running the CW configuration after a full setup, sensorStart/sensorStop with no data-path calls we get:

....
Sensor has been stopped: startCount: 1 stopCount 1
Debug: CRC Channel @080117f8 has been opened successfully
Debug: Launched the mmwaveLink Management Task
Debug: BSS Mailbox Handle @08001d78
Debug: Disabling the device
Debug: BSS Mailbox Handle @08001d78
Debug: Power on request successfully passed to the BSS
RF H/W Version : 02.00
RF F/W Version : 06.03.02.06.20.08.11
RF F/W Patch Version : 00.00.00.00.00.00.00
mmWaveLink Version: 01.02.06.06
Debug: Finished rlEnableContMode
Debug: Finished rlSetContModeConfig

mmwDemo:/>dfeDataOutputMode 2
Done
mmwDemo:/>contModeCfg 60.25, 0, 0, 10000, 0, 131072, 30, 0, 256
gCLI_mmwave_freq_scal_factor is: 256
startFreqConst is: 1497521872
Debug: MmwaveLink_initLink
Debug: MmwaveLink_getVerison:
Debug: MmwaveLink_enableContMode
Debug: MmwaveLink_setContModeConfig
Debug: CW configured, starting sensor...
Debug: sensor start attempted
Done

It seems as though the configuration was taken by the BSS, and may be running.

After this we need to do a sensorSoftReset on the device, since we bypassed the normal call for the CLI sensorStart.  As I mentioned initially, the thrust of my question is there a BSS status call we can make, or a muxed output we can look at with a 'scope to see if the synthesizer is actually running the CW configuration?

Regards,

-TomG.

  • 0
    TI__Genius 14415 points

    Hi Tom,

    Sorry about locking the thread, it started to get duplicated in the other thread and I didn't want the answers to get spread out. Thanks for bringing it back here and summarizing. Just like you see the MmwaveLink_set commands above, there are equivalent _get commands as well. I suggest looking at the mmwaveLink test code for an example of these functions. You can also look at the interface control document (inside the DFP download) for the underlying APIs for this.

    C:\ti\mmwave_sdk_03_06_00_00-LTS\packages\ti\control\mmwavelink

    C:\ti\mmwave_dfp_01_02_06_03\docs

    Regards,

    Jackson

  • +1
    Prodigy 90 points

    Hi Jackson,  

    No problem, I was just confused at first.  They've locked the other thread, so I can't respond there now either, but there was a section in the SBL_design.pdf that initially made me think only the MSS could be re-flashed:

    "4.10 Running the application

    The meta image for SBL application will be created automatically along with the out file upon compiling this application. Note that this image will contain only the MSS binary (no BSS or DSS binary)."

    However, it sounds like that has a different context, so we'll look at this again as we are able.  Thanks to you and Josh Dye for confirming we can load the entire set of code into the secondary boot loader.

    Back to our current development efforts.  We now think the code work for the CW output is potentially running, using the _get command for the temperatures report: rlRfGetTemperatureReport(RL_DEVICE_MAP_INTERNAL_BSS, (rlRfTempData_t*)&tempData); 

    We're able to use a command line to monitor the device temps with the system running, and while idle.   The corresponding output while the device is idle is:

    Debug : Temperature readings

    RX0 :  48 degree C, RX1 :  47 degree C, RX2 :  47 degree C, RX3 :  49 degree C

    TX0 :  47 degree C, TX1 :  49 degree C, TX2 :  49 degree C

    PM  :  49 degree C, DIG0:  49 degree C

    When running the CW code we see an increase in the temperatures as follows:

    Debug: Finished get radarSS bootup status to BSS

    RF H/W Version    : 02.00

    RF F/W Version    : 06.03.02.06.20.08.11

    RF F/W Patch Version : 00.00.00.00.00.00.00

    mmWaveLink Version: 01.02.06.06

    Debug: Finished rlEnableContMode

    Debug: Finished rlSetContModeConfig

    Debug: BootupStatus = 0x2

    Debug: Finished get radarSS bootup status to BSS

    (wait for about 10 seconds...)

    Debug : Temperature readings

    RX0 :  52 degree C, RX1 :  52 degree C, RX2 :  55 degree C, RX3 :  57 degree C

    TX0 :  57 degree C, TX1 :  60 degree C, TX2 :  57 degree C

    PM  :  55 degree C, DIG0:  49 degree C

    Running a standard chirp configuration give us temperatures between these two.  We believe the reason for that is that CW running continuously requires more energy than a framed/chirp configuration which modulates the use of the transmitter(s).  Your input on that point would be of interest.

    We may look at the statusFlags for the RL_RF_AE_MON_SYNTHESIZER_FREQ_REPORT, to see if that confirms the frequency setting for us - assuming this report is valid in CW.

    In any case, let Angie know that her suggestions where helpful to get us to this point.

    Thanks,

    -TomG.

  • 0 in reply to Thomas Grounds
    TI__Genius 14415 points

    Hi Tom,

    Glad it seems to be working. I do agree with your assessment, CW mode will drive the temperature up due to the constant transmit.

    And yes I understand the confusion with the SBL now. The SBL is in itself an application image that resides only in the MSS. At cold boot, that MSS code will be loaded and then will allow the user to either a)load the main image that resides at an offset in the flash, b)load a new image to overwrite the main image in flash, or c) boot from the backup image at a further offset in the flash. All of the images that are loaded BY the SBL will have BSS+MSS+DSS code.

    Regards,

    Jackson

  • 0 in reply to Jackson Thomas
    Prodigy 90 points

    Yes, the SBL code only being in the MSS makes sense.  Thanks, -TomG.