One general rule, is your PDK tests and firmware should come from the same SDK drop. The M3 should be able to access this fine unless maybe the firmware you ran is unmatched with your test binary and it somehow crashed causing issue with that address window. This command is issued from the Cortex-M3 to a dual port instance of the R5 internal memory. Your report about issue with " data.Set 0圆1000000++0x7fff" is odd. This write is happening from the R5 to its own internal memory. I suspect your feedback/report about needing %Long is proper if the ECC is enabled but probably doesn't matter otherwise. These settings set the ECC behavior for the TCMs. When I check my R5 registers, I notice that the ACTLR.B0/B1/TCMPCEN and ACTLR.ATCMECEN bits are cleared as my test system is setup. I often use SD/MMC boot settings but with no card inserted and they work for me. I recall the CCS related instructions for these only test for 'no-boot' mode. There is some sensitivity to the system initial state which can trip up any JTAG flow.
TRACE32 FLASH AUTOSAR CODE
Most likely you have some existing code which ran on the MCU from flash or perhaps you tried a boot mode which I didn't test with. The two issue points you report are not ones I've encountered or seen reported before. I've interacted with several other TRACE32 users who also have used these scripts successfully with PDK and other images (AutoSAR frameworks). Glad that you are able to use the scripts for launching PDK examples.
However if this is really the case, I'm wondering why this was working for you.? I assume (but don't know) that the 32bit accesses are required to initialize the ECC. I was able to solve the problem by using 32bit accesses, i.e. As a result, the rest of the script does not work correctly (the BTCM remains uninitialized). InterCom CR5 Data.Set SD:0x40F80030 %LE %Long 0x0 using VIM_DEDVEC point VIM-VIC vects at ATCM dead loop InterCom CR5 C15:0x119 %Long 0x19 Enable ATCM which appears off after PG1 ROM run (ATCB is on) The second problem I've seen is directly after activating the ATCM, when the BTCM is initialized: I just wonder why code is added anyway although it does not work? And what does "PG1" mean in the script comment? I can see the desired code at address 0x0 when the ATCM is activated by the script afterwards. The reason is probably that the ATCM is still disabled after reset. However when the core is started, the CPU is halted instead and the debugger shows the status "stopped at vector catch".
This doesn't work on PG1 as ATCMA is off and ATCMB is on but not to 0ĭata.Set 0圆1000000++0x7fff %LE %Long 0x0 zero out R5F ATCM to init ECCĭata.assemble sr:0圆1000000 b 0圆1000038 jump to loop pointĭata.assemble sr:0圆1000038 b 0圆1000038 loop have r5 boot into a clean loop instead of abort These instructions shall keep the core in an endless loop when started: Both are related to starting the MCU R5F core.įirst, as far as I understand, the ATCM is filled with two assembler instruction before the core is started. Thanks for the scripts! Basically it seems to work, but there are two positions in the script that do not seem to work as intended.
TRACE32 FLASH AUTOSAR HOW TO
by CCS), since when I start from flash (or CCS), the SciServer runs properly.Īre there any example how to run TRACE32 together with the SDK resp. When I stop the MCU R5F, I can see that an exception occurred in the SciServer. But it does not occur at the beginning, it's somewhere deep in the servers assembler code.Īre there any preconditions expected by the sciserver_testapp that must be set by the debugger manually? It might something that is set by the SBL (resp. But my application then hangs in Board_init(). Now I used the T32 to load the sciserver_testapp_mcu1_0_release.xer5f to the MCU R5F core and let it run before starting the MAIN R5F. The application itself runs properly when starting from Flash via SBL, or when loading it with the Blackhawk debugger and the CCS scripts.
Therefore this application requires an SciServer application running on the MCU R5F. My application runs on the MAIN R5F0 and is based on the PDK from ti-processor-sdk-rtos-j721e-evm-07_03_00_07. I'm currently setting up the Lauterbach debugger on the Jacinto7 by using Lauterbach's example scripts.
0 kommentar(er)
