TDA4VM: NMEVT (input to C66x NMI) seems to vanish in the haze

Hi Wolfgang,

IWS said:

Who can trigger "NMEVT"?

I'll be looking into this question on my end. 

IWS said:

Is there a list of trigger reasons for NMI / NMEVT?
(except the SWE / SWENR instruction)

Currently, as you have pointed out, I'm seeing most of the information of this within TMS320C66x CPU and Instruction Set Reference. Unfortunately there does not seem to be examples beyond describing it occurring during a hardware issue. 

IWS said:

NMI is received after excecution from:
Board_init(boardCfg);
-- within this from.:
if (cfg & BOARD_INIT_PINMUX_CONFIG)
ret = Board_pinmuxConfig();
-- within this from::
Board_STATUS Board_pinmuxUpdate (pinmuxBoardCfg_t *pinmuxData, uint32_t domain)

Could you clarify where in the code base/execution this occurring? Based on this snippet and your description, you are saying the NMI on C66x occurs while executing (what looks like SBL) on the R5F core?

Best,

Asha

Hello Asha,

First: Thanks for statement that there seems to be no list of "hardware issue reasons" - which I would have expected in a "security device".
Indeed I would have expected a Register representing all possible reasons with a bit set at the actual one.
(To me there's a big difference between fetching an illegal opcode, a realized DDR failure, or e.g. a not correct running peripheral).

Second:

Excuse I didn't describe in too much detail as I wanted to learn how to findout myself.
It falls apart into two incidents: 

1.) During Board_sysInit(); I get an interrupt 7 flag set. Interrupts are off at that point, hence nothing happens. But if "someone" fires an interrupt he might have something in his mind that should happen...

2.) Stepping over Board_pinmuxUpdate(gJ721E_WkupPinmuxData, ...) I get an NMI fired, Which might be do to myself.
I of course changed the pinmux config file based on TI's internet pinmux tool and exchanged the files given by the tool. 
I need a "point of origin".

Here are the three first lines of my C66x main:

int main(void)

{

    Board_initCfg boardCfg;

    boardCfg = BOARD_INIT_PINMUX_CONFIG | BOARD_INIT_MODULE_CLOCK | BOARD_INIT_UART_STDIO;

    Board_init(boardCfg);

Within mcu1_0 this code is running:
./packages/ti/drv/sciclient/tools/ccsLoadDmsc/j721e/sciclient_ccs_init_mcu1_0_release.xer5f

Starting to debug main the IFR is all zero.

Jump in:
Board_STATUS Board_init(Board_initCfg cfg) (within pdk_jacinto_09_01_00_22/packages/ti/board/src/j721e_evm/board_init.c)
Jump in (line 198):
Board_sysInit();
Jump in (line 81):
ret = Sciclient_init(&config);
(within /home/wolfgang/gitRepos/iws_tda4psdk/pdk_jacinto_09_01_00_22/packages/ti/drv/sciclient/src/sciclient/sciclient.c)
Jump in (line 567):
status = Sciclient_abiCheck();
Jump in (line 1115):
status = Sciclient_service(&reqPrm, &respPrm);
Jump in (line 195):
return Sciclient_serviceSecureProxy(pReqPrm, pRespPrm);
Jump in (line 861):
Sciclient_sendMessage(txThread,
(const uint8_t *)&gSciclient_secHeader,
gSecHeaderSizeWords,
(uint8_t *) header,
(pReqPrm->pReqPayload +
sizeof(struct tisci_header)),
txPayloadSize,
gSciclient_maxMsgSizeBytes);
run over (“run to last line”)
IFR all zero
Jump out of the function (back to line 870 within Sciclient_serviceSecureProxy).
Now staying at “timeToWait = pReqPrm->timeout;” (halted).
IFR shows IF7=1
Now jumping back all the way “up” back to Board_init….(within board_init.c)
Continuing:
Juming in (at line 192):
ret = Board_pinmuxConfig(); (within pdk_jacinto_09_01_00_22/packages/ti/board/src/j721e_evm/board_pinmux.c)
Jumping over
Board_pinmuxUpdate(gJ721E_WkupPinmuxData,
BOARD_SOC_DOMAIN_WKUP);
Now halted at “return status” of Board_pinmuxConfig IFR shows NMIF=1.

All code is from the psdk.

I need to get closer to the raise of IF7 and I want to understand who & why the NMI is set.

Your help is greatly appreciated, Wolfgang

P.S.: There is some docu on SCI: 
Texas Instruments System Controller Interface (TISCI) — TISCI User Guide
But I didn't manage to squeeze out something that helps me.

Hi Wolfgang,

I do apologize for not getting back to you sooner. Is this still an open issue for you?

If so, thank you for providing the extra information. 

IWS said:

ret = Board_pinmuxConfig(); (within pdk_jacinto_09_01_00_22/packages/ti/board/src/j721e_evm/board_pinmux.c)
Jumping over
Board_pinmuxUpdate(gJ721E_WkupPinmuxData,
BOARD_SOC_DOMAIN_WKUP);
Now halted at “return status” of Board_pinmuxConfig IFR shows NMIF=1.

It seems that the only "custom" things you have done have been changing the pinmux config and the program you are loading on C66. To narrow the issue further down, have you tried running the program with the default pinmux config and seen the results?

Best,

Asha

Hello Asha,

This is still to be understood by me ... :-)
We're at the very first beginning. Right now mcu1_0 runs with the correct pinmux already (in contrast to the post). I don't get the NMI.
I will later try to force it's re-appearance to check if I correctly handle the case.
I'm only a bit confused as in the TI documentation NMI more points to "real" hardware problems and there should be some kind of documentation for it.
But I'll try to look into the mcu1_0 code but I realized it's not easy to debug.
I'll come back to this when I found out more.
Thanks, until then, Wolfgang

Hi Wolfgang,

Thanks for those clarifications. Let me know if it appears again and if you have further questions.

Best,

Asha