AWR1843: DSP/DSS control and debug from the MSS

Wolfgang Hoeld

Prodigy 175 points

Part Number: AWR1843

The following questions pertaint to reset and debug control of the DSS from the MSS side.

The application is running from internal SRAM and any reset or SOFTRESETREQ will rerun the bootloader

and overwrite the information he has downloaded to RAM with the contents from ext. flash.

We have addressed this by enabling ROM eclipsing and performing CR4 reset using the MSS_RCM:SOFTRST1 register.

The question here is if the VIM should be soft reset as well using the SOFTRST2 register?

The second question is on how to restart or control the DSP after a download to the DSP memories. The TRM under

27.2 mentions a Coresight cross trigger module CT-CTA to which the C674x megamodule is connected and which

according to the manual (see figure 27-3):

The second CTI module is present inside the debug subsystem. This CTI receives triggers from ADTF,

DMA, RTI, and WDT. GEM. The C674x DSP can be halted by any trigger in the subsystem. When GEM

trace is enabled, triggers are generated by ADTF by detecting the trigger packets in the trace stream.

However the manual does not state any specifics on this module and as it appears to be custom we would

need additional information on this module like component address, register map, functional description

etc. for CT-CTA component.

Can you elaborate on the CT_CTA component and the functionality of it?

What can the two triggers shown in the TRM do on the DSS side?

Alternatively is there a different way to soft reset the DSP from the CR4 side without rerunnig the bootloader?

Thank's in advance and Best Regards

Wolfgang Hoeld

over 5 years ago

0 Jitendra Gupta over 5 years ago

TI__Guru 69660 points

Hi Wolfgang,

Do you need to reset MSS/DSS under debug condition? If yes, then CCS IDE does that for you, where even after image loaded to DSS/MSS you can reset the cores and re-load the image and run. Or if you are trying to setup with different IDE?

It would be good if you provide the usecase of reset/halt of the cores to help us understand more and provide the solution.

Regards,

Jitendra

0 Wolfgang Hoeld over 5 years ago in reply to Jitendra Gupta

Prodigy 175 points

Hello Jitendra,

thank's for your reply. Iam aware that CSS does all this but we are a tools provider (iSYSTEM) and we need to

implement a solution which is similar to what you do in CSS. However as outlined the key is to do all this from

the CR4 side without touching the DSP Megamodule debug throug the IcePick. Hence, just the Coresight components

is what we see from our debugger and we would need the sequence/access to properly reset and control the DSS

side from that.

Best Regards,

Wolfgang Hoeld

0 Jitendra Gupta over 5 years ago in reply to Wolfgang Hoeld

TI__Guru 69660 points

Hi Wolfgang,

I would suggest you refer C:\ti\<ccs path>\ccs_base\emulation\gel\xwr16xx_dss_init.gel file where it has functions to halt, reset of DSS core. All the addressing is from MSS core so you can use those addresses writing from MSS.

To Reset DSS: WR_MEM_32(0xFFFFE10C, 0x070000AD); /* ASSERT RESET */

WR_MEM_32(0xFFFFE10C, 0x07000000); /*De-ASSERT RESET */

After this you can download image from MSS or from DAP then un-halt the DSS using above said gel file (Function DSS_ReleaseDSPHalt).

You don't need to reset VIM after eclipsing MSS, as the application's driver initialization should do this reset usually.

Regards,

Jitendra

0 Wolfgang Hoeld over 5 years ago in reply to Jitendra Gupta

Prodigy 175 points

Hello Jitendra,

thank you very much for your answers. I spent some time reviewing this agains the manual and have reviewed the

gel files.

The information on how to reset the DSS (soft reset) form the MSS is very clear and helpful (even the manual just

lists that field/value 0xAD as reserved in the DSSCTL register at FFFFE10C.

As far as halting/unhalting the DSS is concerned I found the functions in the xwr16xx_dss_cdap.gel file.

I think this answers all the questions.

Thank's and best Regards

Wolfgang Hoeld

0 Wolfgang Hoeld over 5 years ago in reply to Wolfgang Hoeld

Prodigy 175 points

Hello Jitendra,

after reviewing the .gel file I noted that there is one register which is used to check the power status of

the DSS which I was not able to resolve - PWRAP_DPREC0 and it's associated bits. It looks like it

might be a custom coresight component or access port?

Could you elaborate on it pls.

Best Regards,

Wolfgang

0 Jitendra Gupta over 5 years ago in reply to Wolfgang Hoeld

TI__Guru 69660 points

Hi Wolfgang,

Looks like it is DAP access port related variable used in the gel file. This is some variable used internally by CCS DAP which I don't find the explanation in the CCS

Let me check with the concern team and get back to you.

Regards,

Jitendra

0 Jitendra Gupta over 5 years ago in reply to Jitendra Gupta

TI__Guru 69660 points

Hi Wolfgang,

xwr16xx_dss_csdap.gel uses PWRAP_DPREC0 variable to check the DSS power-off or reset status. This can be checked using DSS_REG_GEMPWRSMCFG3_REG register.

gempwrsmcfg3_rd = HW_RD_REG32(DSS_REG_GEMPWRSMCFG3_REG);

power_status = (gempwrsmcfg3_rd >> 18) & 0x3 ;

if((0x00000000 == (pwrap_dprec0_rd & 0x00000020)) || (0x00020000 == (pwrap_dprec0_rd & 0x0007C000))) -->> if(power_status != 0x3)

/* power_status == 3 means DSS is powered ON */

Regards,

Jitendra

0 Wolfgang Hoeld over 5 years ago in reply to Jitendra Gupta

Prodigy 175 points

hi Jitendra,

o.k - I am checking the power status instead no problem. However the underlying problem is that I

Halt the DSP the following way:

Check PWRSTATUS - if ON proceed
Info - GEMRSTCAUSE 0x00010101
Set GEMPWRSMCFG4.PWRSMLRSTHALT
Write 0x070000AD to 0xFFFFE10C
Write 0x07000000 to 0xFFFFE10C
Check PWR status = OFF
Info - GEMRSTCAUSE 0x000B0B03

To restart the DSP I implemented the steps in the xwr16xx_dss_csdap.gel file. However the problem is

that despite of clearing GEMPWRSMCFG4.PWRSMLRSTHALT and unmasking GEMPWRSMCFG4.GEMEVENTMASK

the PowerStatus remains 0x0 = OFF. Hence it seems I can properly stop the DSP with a local reset but I can not

restart it.

Any ideas on what to check or what could be wrong? Maybe the TI tools stop the DSP in a different way then I do?

Thank's in advance for your help.

Wolfgang

0 Jitendra Gupta over 5 years ago in reply to Wolfgang Hoeld

TI__Guru 69660 points

Hi Wolfgang,

After reset (above sequence) you need to un-halt the DSS again (execute DSS_ReleaseDSPHalt function from *.gel file).

Regards,

Jitendra

0 Wolfgang Hoeld over 5 years ago in reply to Wolfgang Hoeld

Prodigy 175 points

Hello Jitendra,

yes this is exactly what I am doing - as I wrote:

To restart the DSP I implemented the steps in the xwr16xx_dss_csdap.gel file. However the problem is

that despite of clearing GEMPWRSMCFG4.PWRSMLRSTHALT and unmasking GEMPWRSMCFG4.GEMEVENTMASK

the PowerStatus remains 0x0 = OFF. Hence it seems I can properly stop the DSP with a local reset but I can not

restart it.

What I see is that device does not restart. The gel file has a section where it checks if the STC was triggered by

the bootloader:

// Check if DSS_STC is triggered by Bootloader
       if(0x1 == (stcgstat_rd & 0x1))
       {
           unsigned int stcpbistsmcfg1_rd = HW_RD_REG32(DSS_REG_STCPBISTSMCFG1_REG);
           unsigned int stcpbistsmcfg1_wr = 0;

           // Clear bit 3
           stcpbistsmcfg1_wr = stcpbistsmcfg1_rd & (~(1 << 3));
           HW_WR_REG32(DSS_REG_STCPBISTSMCFG1_REG, stcpbistsmcfg1_wr);
       }

That code was implemented as well and I see it being executed. Following it I unhalt the DSP power

state machine by clearing GEMPWRSMCFG4.PWRSMLRSTHALT. I then poll the power status for 1 sec

but it remains 00. Rerunning the function later stiil yields a power status of 00.

I hope that makes clear what the problem is - it is restarting the DSP with the sequence used in the

gel function DSS_ReleaseDSPHalt().

Has anybody successfully used this after halting the DSP with a reset?

Best Regards

Wolfgang

0 Jitendra Gupta over 5 years ago in reply to Wolfgang Hoeld

TI__Guru 69660 points

Hi Wolfgang,

This is what I have tried at my end with AWR1843 device.

1. Flash the mmw demo and run in SOP-4 mode.

2. Connect CCS to the device, able to connect MSS and DSS core.

3. Disconnect DSS core but connect only MSS core.

4. From MSS core: Write 0xFFFFE10C[0:7] = 0x070000AD and then 0x07000000 to reset the DSS.

- not able to connect to DSS core at this point

5. Then execute DSS_ReleaseDSPHalt function from the gel file.

6. Now able to connect back to DSS core.

So effectively with these steps, I'm able to reset the DSS core.

Regards,

Jitendra

0 Wolfgang Hoeld over 5 years ago in reply to Jitendra Gupta

Prodigy 175 points

Hello Jitendra,

unfortunately this only prooves that the TI tools are working as expected. I believe the anser is in

what is being done when the TI tools first connect to either core.

I can see that the reset of the DSP core work as after that sequence the DSS is not powered/clocked and

access to the DSP L2 and L1 memories is no longer possible.

The problem is still with restarting the DSS side. Here is a log output of my script:

I 01B : AWR1843 Release DSP from Halt after reset - STARTED
I 01B :
I 01B : Read: 0x500006C8
I 01B : Value: 0x00014514
I 01B :
I 01B :     DSP domain power status - GEM OFF
I 01B : PWSMMODESTATUS 0x00000000
I 01B :
I 01B : Read: 0x500006CC
I 01B : Value: 0x00FE0080
I 01B :
I 01B :     DSP halted by PWRSMLRSTHALT - ok
I 01B :
I 01B : Read: 0x50040014
I 01B : Value: 0x00000500
I 01B :
I 01B :     DSS_STC was triggered by bootloader
I 01B :
I 01B : Read: 0x5000074C
I 01B : Value: 0x00000018
I 01B :
I 01B : Write: 0x5000074C
I 01B : Value: 0x00000010
I 01B :
I 01B :     Clear GEMPWRSMCFG4.PWRSMLRSTHALT to restart the DSP
I 01B :
I 01B : Read: 0x500006CC
I 01B : Value: 0x00FE0080
I 01B :
I 01B : Write: 0x500006CC
I 01B : Value: 0x00FC0080
I 01B :
I 01B :     Unmask/clear GEMPWRSMCFG4.GEMEVENTMASK
I 01B :
I 01B : Read: 0x500006CC
I 01B : Value: 0x00FC0080
I 01B :
I 01B : Write: 0x500006CC
I 01B : Value: 0x00F80080
I 01B :
I 01B :     Waiting for DSP to power up
I 01B :
I 01B : Read: 0x500006C8
I 01B : Value: 0x00014514
I 01B : PWSMMODESTATUS 0x00000000

This goes on until a timeout (1 sec) ...... occurs

I 01B : Read: 0x500006C8
I 01B : Value: 0x00014514
I 01B : PWSMMODESTATUS 0x00000000
I 01B :
I 01B : DSP did not power up - TIMEOUT!
E 01B : Power up of DSP timed out

If I understand the manual correctly the DSP side requires a trigger in order to wake up. I get this from

the RM 4.4.2.2 Power ON Control Sequence under items #2 and #4 it states to unmask the wakeup

event and to trigger a wakeup event. Hence the gel file sequence is only a subset of this whole procedure

described in the refmanual.

In addition there are two additional access ports and from waht I analyzed one is most likely the one

holding the Power_DPRegs(s) registes while the other could be the one associated with the triggers from the MSS

coresight modules to the DSS side:

AP:sel:0x0000000004000000, id:0x002e0001 (AP is NOT ARM)
AP:sel:0x0000000005000000, id:0x34770002 (ARM APB2-AP)
AP:sel:0x0000000006000000, id:0x54770001 (ARM AHB3-AP)
AP:sel:0x0000000007000000, id:0x002e0002 (AP is NOT ARM)

Could you pls elaborate on the above points:

Trigger required to restart the DSS and how to generate them?
Additional access ports and their functionality (trigger? Power_DPRegs

Thank's and Best Regards,

Wolfgang

0 Wolfgang Hoeld over 5 years ago in reply to Jitendra Gupta

Prodigy 175 points

Hello Jitendra,

unfortunately this only prooves that the TI tools are working as expected. I believe the anser is in

what is being done when the TI tools first connect to either core.

I can see that the reset of the DSP core work as after that sequence the DSS is not powered/clocked and

access to the DSP L2 and L1 memories is no longer possible.

The problem is still with restarting the DSS side. Here is a log output of my script:

This goes on until a timeout (1 sec) ...... occurs

I 01B : Read: 0x500006C8
I 01B : Value: 0x00014514
I 01B : PWSMMODESTATUS 0x00000000
I 01B :
I 01B : DSP did not power up - TIMEOUT!
E 01B : Power up of DSP timed out

If I understand the manual correctly the DSP side requires a trigger in order to wake up. I get this from

the RM 4.4.2.2 Power ON Control Sequence under items #2 and #4 it states to unmask the wakeup

event and to trigger a wakeup event. Hence the gel file sequence is only a subset of this whole procedure

described in the refmanual.

In addition there are two additional access ports and from waht I analyzed one is most likely the one

holding the Power_DPRegs(s) registes while the other could be the one associated with the triggers from the MSS

coresight modules to the DSS side:

Could you pls elaborate on the above points:

Trigger required to restart the DSS and how to generate them?
Additional access ports and their functionality (trigger? Power_DPRegs

Thank's and Best Regards,

Wolfgang

0 Jitendra Gupta over 5 years ago in reply to Wolfgang Hoeld

TI__Guru 69660 points

Hi Wolfgang,

We are checking this with the team internally. We will update you soon.Thanks for your patience.

Meanwhile, Instead of resetting DSP, you can reset the PC to first location so application can start executing from the beginning again.

Regards,

Jitendra

0 Jitendra Gupta over 5 years ago in reply to Wolfgang Hoeld

TI__Guru 69660 points

Hello Wolfgang,

Based on internal team response:

He needs to follow the exact power on sequence as mentioned in the TRM :

3.4.2.2 Power ON Control Sequence

Below is the detailed sequence to power on the DSP.

Master subsystem-controlled DSP power ON sequence — This sequence is used to power on the DSP core.

1. Unmask the wakeup event: by default, all DSP interrupts are masked as wakeup events. To unmask a

wakeup event, write the corresponding bit in registers DSS_REG.PWRSMWAKEMASK[0-2]. The 96-bit

configuration corresponds to the [95:0] interrupt lines to the DSP.

2. If the program code must be downloaded into the DSP L2 memory before starting the DSP execution,

then set the DSS_REG.GEMPWRSMCFG4.PWRSMLRSTHALT bit to 0x1.

3. Trigger the wakeup: when an unmasked interrupt is generated to the DSP, a wakeup trigger is

generated.

4. Wait for GEM to be powered on by polling the field DSS_REG.GEMPWRSMCFG4.PWRSMSTATE for

the value 0xB. SW can now configure and trigger the DMA for the program code download.

5. When the program code is completed, SW can now release the halt by clearing the

DSS_REG.GEMPWRSMCFG4.PWRSMLRSTHALT bit; DSP begins execution.

6. Follow the steps in the DSP Execution on Power ON section below.

He only seems to be configuring DSS_REG.GEMPWRSMCFG4.PWRSMLRSTHAL and DSS_REG.GEMPWRSMCFG4.GEMEVENTMASK.

I do not see any Wake up trigger in his sequence. Please check.

Could you verify if you have the exact flow given in TRM section mentioned above?

Regards,

Jitendra

0 Wolfgang Hoeld over 5 years ago in reply to Jitendra Gupta

Prodigy 175 points

Hello Jitendra,

thank's for the info but unfortunately we are going a bit in a circle. My previous questions was exactly related to the following statement in the manual:

3. Trigger the wakeup: when an unmasked interrupt is generated to the DSP, a wakeup trigger is

generated.

I am aware of the fact that a wakeup event is required and that it needs to be unmasked. However the TRM makes no mention on how to actually

trigger (or generate) the wakeup event. On the other side the debug system block diagram (Figure 27-2) shows a "Triggers" module which is not

shown in the associated table 27-2.

I was under the impression that those triggers could be used to trigger a wakeup of the DSP. But in any case let me rephrase my question:

How can an unmasked interrupt - which results in a wakeup event - be triggered from the CR4 debug subsystem?

Best Regards,

Wolfgang

0 Jitendra Gupta over 5 years ago in reply to Wolfgang Hoeld

TI__Guru 69660 points

Hello Wolfgang,

Just a note based on the latest feedback:

Reset of DSS (sub-system) is not supported in mmWave Sensor but DSP core reset is possible.

On top of the above all the sequence, You can use SW interrupts from MSS that go to the DSP interrupt map. It's used to generate a wakeup trigger from the DSP to finally restart the core.

Enable the MSS DMM SW interrupt 4 as a DSP wakeup event : Reg_Write[0x500006D8] = 0xFFFF7FFF;

then trigger the MSS DMM SW Interrupt 4 : Reg_Write[0xFFFFF948] = 0x10;

Let me know these steps help you further.

Regards,

Jitendra

0 Wolfgang Hoeld over 5 years ago in reply to Jitendra Gupta

Prodigy 175 points

Thank's a lot. This does the trick. Please note that even the mentioned registered are in the device XML files they

are missing from the technical refereence mannual.

Best Regards,

Wolfgang

Sensors

Sensors forum

AWR1843: DSP/DSS control and debug from the MSS