• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 100 subscribers
  • Views 1646 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.

Linux/AM5728: HTTPS node.js server issue

Luis Montoya
Prodigy 50 points
Part Number: AM5728


Tool/software: Linux

Hi.

I have a system using the AM5728 evm with Linux on A15 and TI-RTOS on DSP core.

Our DSP1 firmware uses MCASP5, and IPC/CMEM to communicate with an application running on A15/Linux.

we are creating a WebServices Server under Node.js. the Server works fine if use HTTP.

but, when we change to encrypted HTTPS:

1.- if we load the DSP1 with our custom firmware then node.js server stuck and the only way to stop is rebooting the system (can't stop using Ctrl ^C).

2.- if we unload the DSP1 firmware then the https module works 100%

what can be issue? any ideas?

Thank you.

  • 0
    TI__Guru 50170 points
    Hi, Luis,

    It sounds like everything works as long as the DSP1 is not running McASP application. Is that true? I am checking with DSP engineer who is familiar with McASP to see possible conflicts from it. By the way, what's the Processor SDK release you are using?

    Rex
  • 0 in reply to Rex Chang
    Prodigy 50 points
    Yes, everything works as long as DSP core is not loaded with the firmware. Loading firmware on the DSP core causes node js application with https module to freeze. Our DSP core firmware uses TI RTOS drivers for MCASP and I2C and communicates with a C++ application on the Linux using IPC and CMEM. We are using Processor SDK v4.03
  • 0 in reply to Luis Montoya
    TI__Guru 50170 points
    Hi, Luis,

    I am not sure if this applies to your case. Could you check in your DSP code accesses MMR_LOCK_2 and trying to unlock/lock it? This is an issue I can think of that DSP may affect ARM, but should have been fixed in CSL since PSDK 4.2 unless you unlock/lock MMR_LOCK_2 directly in DSP code. Could you verify it while I am searching for other possible causes?

    Rex
  • 0 in reply to Rex Chang
    Intellectual 570 points

    Hi Rex,

    I worked on the DSP core firmware and I based it on the MCASP_DeviceLoopback example project from the pdk_am57xx_1_0_10. In the DSP, I don't have any code that is directly unlocking/locking MMR_LOCK_2.

    Thanks,

    Jimit

  • 0 in reply to Jimit Patel
    TI__Guru 50170 points
    Hi, Luis & Jimit,

    From the description of the issue, it seems to me that the DSP McASP application is loaded during kernel boot up by remoteproc. When HTTPS server runs later, system hangs. Could you try get the HTTPS going first without DSP image, then load the dsp image to see if that kills the HTTPS service. If it does, could you debug the DSP code to see which instruction causes the HTTPS stop working?

    Rex
  • 0 in reply to Rex Chang
    Intellectual 570 points

    Hi Rex,

    You are right, the DSP application is being loaded during the kernel boot up by remoteproc and when the https server runs later, the system hangs.

    I tried launching https web server first and then running the DSP image. This doesn't kill the https server. The server works as expected. But after this, if I restart the https web server then it hangs up the system.

    We would like to have ability to restart https server independently without having need to have a startup sequence or startup synchronization with the DSP core... The code we are planning to run on the DSP and M4 (IPU1) is more critical to our system operations and would not be able tolerate unload/load operation whenever the https server restarts. Can you please help us find a solution to this?

    Thanks,
    Jimit

  • 0 in reply to Jimit Patel
    TI__Guru 50170 points

    Hi, Jimit,

    It will need to debug for the root cause of the issue. In this case, you may want to see what does the HTTPS do and what the system doing at the time of hung. Then, go from there.

    Rex

  • 0 in reply to Rex Chang
    Intellectual 570 points
    Hi Rex,

    I was able to narrow down this issue to Configure_XBAR() -

    CSL_xbarDmaConfigure(CSL_XBAR_DMA_CPU_ID_EDMA,128,1+CSL_EDMA3_CHA_MCASP0_RX);
    CSL_xbarDmaConfigure(CSL_XBAR_DMA_CPU_ID_EDMA,129,1+CSL_EDMA3_CHA_MCASP0_TX);

    I had used MCASP_DeviceLoopback example project as base and so this was included in the build. I removed these lines since I am not using MCASP0 and now I can run the node server using https without any issues. I still don't understand how these can be related. Anyways, issue is resolved.

    Thanks,
    Jimit
  • 0 in reply to Jimit Patel
    TI__Guru 50170 points
    Hi, Jimit,

    That was what I originally thought which configures xbar causing the issue. There is an errata of Advisory 30 Usage Note 4 in www.ti.com/.../sprz334h.pdf. To work around, Linux unlock the MMR_LOCK_2 and the value shouldn't be touched afterward. When configuring xbarDma, MMR_LOCK_2 is modified by DSP. This issue should have been fixed in CSL library in Processor SDK 4.2 and newer. I'll track it down to tie the loose end.

    I am glad your issue is resolved. Thanks for letting me know.

    Rex