Other Parts Discussed in Thread: AWR1843
大家好,我在制作AWR1843的SBL的时候,用UIFLASH烧录SBL‘bin文件后,可以正常下载APP,但是重新上下电一直错误帧,单独刷写APP的文件时重新上下电会发送一帧报文。用CCS看PRAM地址时,发现单独刷写APP和用我制作的SBL下载APP 后,0x000--0x2000地址上内容一致,请问为什么程序在SBL引导下不正常呢?
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.
大家好,我在制作AWR1843的SBL的时候,用UIFLASH烧录SBL‘bin文件后,可以正常下载APP,但是重新上下电一直错误帧,单独刷写APP的文件时重新上下电会发送一帧报文。用CCS看PRAM地址时,发现单独刷写APP和用我制作的SBL下载APP 后,0x000--0x2000地址上内容一致,请问为什么程序在SBL引导下不正常呢?
您好,由于导入工程方便,我们是基于C:\ti\mmwave_automotive_toolbox_3_6_0\labs\lab0012_can_sbl进行开发,有参考相关design文档。
在原sbl工程基础上加入移植UDS相关应用层,但是建sbl_initTask之前的初始化完全复用原sbl工程,且App的引导及后续反初始化是完全复用image_Loader及其以后函数的。在debug模式下,通过在SOC_softreset函数前下断点的时候拉取TCMA内容,我们发现与直接下载App的bin文件后拉取到的TCMA内容相同。
请问还有哪些引导失败的可能原因呢?
但是重新上下电一直错误帧
是APP里CAN数据帧错误,还是毫米波帧错误?
您好,我们在mcal里配置的polling轮询方式而非中断,理论上不涉及到中断问题。另外就是在引导进入App之前,我只调用了Can_init、Can_ReadMainfunction以及Can_deinit,只有尝试读取报文并没有发送报文的操作。
另外,上面说的错误帧是指CAN的ack错误帧,我们判断是App引导失败导致CAN deinit以后没有再初始化,导致CAN收发器没有重新使能造成了CAN掉线。
你好,
你的意思是烧写sbl+app后,外部CAN设备向AWR1843发送CAN报文,但没有ack么?
你使用了mcal?还是笔误是MCAN?
我们判断是App引导失败导致CAN deinit以后没有再初始化,导致CAN收发器没有重新使能造成了CAN掉线。
原始的sbl能否正常引导app启动?
1、是这样的no ack。
2、非笔误,sbl里的mcan的驱动是MCAL而非mmwave sdk,app里的mcan目前还是基于sdk的。但是我们的FAE Allen没能在SBL相关问题上给我们提供进一步帮助。
3、我们把app烧到backup分区(也就是metaImage4)+原始sbl,上电20s后有App的CAN报文发出。
你好,
你们能否再定位一下是app没有正常启动,还是只是APP里can没有正常发送数据?能否在app启动最开始的地方加上gpio拉高拉低的测试口信号测量来确认?
AWR1843AOP: qspiflash初始化后,为何需等待一段时间才能读到flash数据 - 传感器论坛 - 传感器 - E2E 设计支持 (ti.com)
qspiflash驱动的问题,导致上电读不到flash数据,临时加个启动延时就好了。具体flash问题还在排查