AWR6843: Image Load/ Parsing not completed in CAN Secondary Bootloader

Hi,

Have you confirmed that the CAN module is correctly configured? Pinmux will need to be changed to match the AWR6843 device, and the CAN module would need to be configured properly to match whatever configuration is used on the other side of the bus. You are using the MCAN module for CANFD, correct?

Best Regards,
Alec

Hi Alec,

thanks for your response. Yes, the Pinmux is already adapted. CAN communication is working because we are able to transfer our binary image file and the message " Debug: Total data written = " is seen in the UART output.

After this the SBL_imageLoader() is triggered and it does not seem to return.

No further "Debug: " or "Error: " messages were printed in the UART output.

Regards,

Aghil

Hi Aghil,

Understood. Is this device either a secure or safety enabled part, or just a general one?

Best Regards,
Alec

Aghil,

Additionally, do you have the capability to do some debugging in the SBL_imageLoader function? Either by stepping through or by using debug output lines so that we can get a better idea of exactly where you are getting hung up? I do not see any immediate issues that would cause any issue, so I may need some help from you to determine exactly what is happening.

In the meantime, another datapoint you can look at for comparison is the SBL over SPI code, which can be found in the mmWave industrial toolbox under <Industrial_Toolbox_Location>/labs/common/src/utils/sbl/

This version should be compatible with both 18xx and 68xx, so most of the code should be similar to what you are using, but with SPI rather than CAN.

Best Regards,
Alec

Hi Alec, just a general device.

Regards,

Aghil

Hi Alec, yes, I have already compared the SBL code mmWave industrial toolbox under <Industrial_Toolbox_Location>/labs/common/src/utils/sbl/ and we do have taken the Spi configuration because we use a CAN transceiver with Spi. The related Pinmux is adapted as well.

As mentioned in my first post, I did debug by adding SBL_printf() at suspicious lines of code. It was found that the parsing was not completed - something seemed wrong with "Number of files done parsing" (gSblMCB.numFilesWritten) and "Number of files present" gSblMCB.metaHeader.numFiles). They never matched. Do this give some hints to you?

Regards,

Aghil

Aghil,

Understood, just to be clear, which of these two fields was correct and which was incorrect? An example of what values you saw may be beneficial.

Best Regards,
Alec

Aghil,

Additionally, are you writing an image for just the MSS(1 core) or for both the MSS and the DSS (2 Core)?

Best Regards,
Alec

Hi Alec,

yes, only write an image for just the MSS(1 core).

I did debug further into the SBL Image Parser function and could observe that the SW stops in the SBL_readRPRCSecContent() function at the first memcpy call. Please see the "Debug: SBL_readRPRCSecContent 3 ..." statements. 

In the last print, the sectionPtr (section current address) jumped to 0x4000 0000. I have attached the section address prints from the start of the parsing and also the errorStatus value.

Any idea what the gSblMCB.errorStatus value 4000 0000 means? I could not find it in the sbl.error.h file.

Debug: SBL_readRPRCSecContent 3 68 134344976
Debug: SBL_readRPRCSecContent 3 256 134345096
Debug: SBL_readRPRCSecContent 3 272 134345128
Debug: SBL_readRPRCSecContent 3 1896 134344832
Debug: SBL_readRPRCSecContent 3 3944 134344832
Debug: SBL_readRPRCSecContent 3 5992 134344832
Debug: SBL_readRPRCSecContent 3 8040 134344832
Debug: SBL_readRPRCSecContent 3 10088 134344832
Debug: SBL_readRPRCSecContent 3 12136 134344832
Debug: SBL_readRPRCSecContent 3 14184 134344832
Debug: SBL_readRPRCSecContent 3 16232 134344832
Debug: SBL_readRPRCSecContent 3 18280 134344832
Debug: SBL_readRPRCSecContent 3 20328 134344832
Debug: SBL_readRPRCSecContent 3 22376 134344832
Debug: SBL_readRPRCSecContent 3 24424 134344832
Debug: SBL_readRPRCSecContent 3 26472 134344832
Debug: SBL_readRPRCSecContent 3 28520 134344832
Debug: SBL_readRPRCSecContent 3 30568 134344832
Debug: SBL_readRPRCSecContent 3 32616 134344832
Debug: SBL_readRPRCSecContent 3 34664 134344832
Debug: SBL_readRPRCSecContent 3 36712 134344832
Debug: SBL_readRPRCSecContent 3 38760 134344832
Debug: SBL_readRPRCSecContent 3 40808 134344832
Debug: SBL_readRPRCSecContent 3 42856 134344832
Debug: SBL_readRPRCSecContent 3 44904 134344832
Debug: SBL_readRPRCSecContent 3 46952 134344832
Debug: SBL_readRPRCSecContent 3 49000 134344832
Debug: SBL_readRPRCSecContent 3 51048 134344832
Debug: SBL_readRPRCSecContent 3 51368 134345176
Debug: SBL_readRPRCSecContent 3 53072 134344832
Debug: SBL_readRPRCSecContent 3 55120 134344832
Debug: SBL_readRPRCSecContent 3 57168 134344832
Debug: SBL_readRPRCSecContent 3 59216 134344832
Debug: SBL_readRPRCSecContent 3 61264 134344832
Debug: SBL_readRPRCSecContent 3 66612 134346416
Debug: SBL_readRPRCSecContent 3 67076 134344832
Debug: SBL_readRPRCSecContent 3 69124 134344832
Debug: SBL_readRPRCSecContent 3 71172 134344832
Debug: SBL_readRPRCSecContent 3 73220 134344832
Debug: SBL_readRPRCSecContent 3 75268 134344832
Debug: SBL_readRPRCSecContent 3 77316 134344832
Debug: SBL_readRPRCSecContent 3 79364 134344832
Debug: SBL_readRPRCSecContent 3 80292 134345784
Debug: SBL_readRPRCSecContent 3 81388 134344832
Debug: SBL_readRPRCSecContent 3 83436 134344832
Debug: SBL_readRPRCSecContent 3 85484 134344832
Debug: SBL_readRPRCSecContent 3 87532 134344832
Debug: SBL_readRPRCSecContent 3 89580 134344832
Debug: SBL_readRPRCSecContent 3 91628 134344832
Debug: SBL_readRPRCSecContent 3 92092 134345320
Debug: SBL_readRPRCSecContent 3 93652 134344832
Debug: SBL_readRPRCSecContent 3 94660 134345864
Debug: SBL_readRPRCSecContent 3 95676 134344832
Debug: SBL_readRPRCSecContent 3 99056 134346184
Debug: SBL_readRPRCSecContent 3 99752 134344832
Debug: SBL_readRPRCSecContent 3 100840 134345944
Debug: SBL_readRPRCSecContent 3 101776 134344832
Debug: SBL_readRPRCSecContent 3 102240 134345312
Debug: SBL_readRPRCSecContent 3 103596 134346696
Debug: SBL_readRPRCSecContent 3 103780 134344832
Debug: SBL_readRPRCSecContent 3 104472 134345552
Debug: SBL_readRPRCSecContent 3 105072 134346176
Debug: SBL_readRPRCSecContent 3 105100 134346232
Debug: SBL_readRPRCSecContent 3 105120 134346280
Debug: SBL_readRPRCSecContent 3 105720 134344832
Debug: SBL_readRPRCSecContent 3 1073741824 134346416

Regards,

Aghil

Alec, 

regarding the rprc file, in our application project post-build step we have already adapted to the rpcc.bin for 68xx and it is included during the  MulticoreImageGen. However, in our 68xx Bootloader project, during the MulticoreImageGen step, i do not see any rprc bin file being included.

Please see the screenshot of the out2rprc and MulticoreImageGen steps below.

Should i configure the appropriate rprc.bin in the CCS somewhere?

Regards,

Aghil

Aghil,

Got it. Another idea, can you compare your src files for the SBL in your project to the ones in the mmWave sdk? perhaps there is an outdated SBL src file in the CAN SBL project that has since been updated in the SDK.

Best Regards,
Alec

Alec, 

I did compare my project files with the files in the mmWave SDK. We do have project specific differences e.g. in the sbl.c. Unfortunately do not see any "outdated" things. 

Refering to the screenshot in my last second post - any idea what the errorStatus 40000000 signifies? I did not see this error value in sbl_error.h file.

Also why does the sectionPtr have the same value as the errorStatus? Seems also strange that the sectionPtr made a jump from address 19AA0 to 40000000 . 

Best regards

Aghil

Aghil,

Understood. I have reached out to the field representative that works with you to see if we can get a debug session scheduled so that we may hopefully be able to come to a resolution more quickly. 

I realize I don't think that I have ever asked, but has the image that you are sending over CAN been verified via uniflash to ensure the image is good? I would assume so but wanted to verify.

Best Regards,
Alec

Alec, 

yes, sure. I did flash the same image over uniflash and it was fine. 

Yesterday I tried one another thing. The image sent over CAN includes both MSS and RSS images (post build combines both MSS and RSS). I excluded the RSS image from the post build step. Then, just sent the MSS image. In this case, the Parsing was completed. However, the application did not start. I guess becuase there is no RSS image.

Thus, it seems like parsing of the xwr68 RSS does not finish. The xwr18xx RSS image size is 34 KB and but the xwr68xx RSS is 247 KB. Could this be an issue for the parser?

We have the following shared memory allocation to different cores - 0x00000006 [BSS|MSS TCMB|MSS TCMA|DSS]. Does this fit with the RSS image size?

Best regards

Aghil

Aghil,

There shouldn't be any issue doing the RSS image parsing, since the UART SBL works on 68xx devices. Since we have an offline debugging session scheduled, I will leave this thread inactive until we have a solution and can update it with the solution that we have found.

Best Regards,
Alec

Hi, Aghil

can you share with me the can sbl project （or your project setting）,  I am also studying CAN SBL project recently ,running the lab (can sbl )from automotive toolbox on AWR6843isk + DCA1000.  But it still adnormal。

Thanks a lot
Allen

Hi Allen,

regarding my project settings, please see my first post.

Best regards

Aghil