• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 1413 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.

TDA4VM: TRACE32 and SciServer

Thomas Dedler
Intellectual 270 points
Part Number: TDA4VM
Other Parts Discussed in Thread: DRA829

Hello,

I'm currently setting up the Lauterbach debugger on the Jacinto7 by using Lauterbach's example scripts. My application runs on the MAIN R5F0 and is based on the PDK from ti-processor-sdk-rtos-j721e-evm-07_03_00_07. Therefore this application requires an SciServer application running on the MCU R5F.

The application itself runs properly when starting from Flash via SBL, or when loading it with the Blackhawk debugger and the CCS scripts.

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. But my application then hangs in Board_init(). 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.

Are 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. by CCS), since when I start from flash (or CCS), the SciServer runs properly.

Are there any example how to run TRACE32 together with the SDK resp. PDK examples?

Regards

Thomas

  • +1
    TI__Mastermind 23395 points

    Hello Thomas,

    Yes, I have ran PDK examples from TRACE32/Lauterbach with the SDK 7_03. I'll attach a set of scripts which should work if you update the paths to binaries inside the CMMs.  For R5 loading see the script ./cmm-tda4_dra829/x_gel_to_cmm_public/pdk_rtos_test/pdk_launch_js_r5.cmm.  You will need to repower the board in between runs as the bare metal DDR init for the EVM expects the DDR to be in its reset state.

    /cfs-file/__key/communityserver-discussions-components-files/791/cmm_2D00_tda4_5F00_dra829.7z

    The bare metal scripts were mostly autogenerated using the TRACE32 gel_converter.  If the readme is followed it is possible to add your own board.

    Regards,

    Richard W.

  • 0 in reply to Richard Woodruff
    Intellectual 270 points

    Hello Richard,

    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. Both are related to starting the MCU R5F core.

    First, as far as I understand, the ATCM is filled with two assembler instruction before the core is started. These instructions shall keep the core in an endless loop when started:

    ; have r5 boot into a clean loop instead of abort
    ; This doesn't work on PG1 as ATCMA is off and ATCMB is on but not to 0
    data.Set 0x61000000++0x7fff %LE %Long 0x0 ; zero out R5F ATCM to init ECC
    data.assemble sr:0x61000000 b 0x61000038 ; jump to loop point
    data.assemble sr:0x61000038 b 0x61000038 ; loop

    However when the core is started, the CPU is halted instead and the debugger shows the status "stopped at vector catch". The reason is probably that the ATCM is still disabled after reset. I can see the desired code at address 0x0 when the ATCM is activated by the script afterwards. I just wonder why code is added anyway although it does not work? And what does "PG1" mean in the script comment?

    The second problem I've seen is directly after activating the ATCM, when the BTCM is initialized:

    InterCom CR5 PER.Set.simple C15:0x119 %Long 0x19  ; Enable ATCM which appears off after PG1 ROM run (ATCB is on)
    InterCom CR5 Data.Set SD:0x40F80030 %LE %Long 0x0 ; using VIM_DEDVEC point VIM-VIC vects at ATCM dead loop
    InterCom CR5 data.set 0x41010000--0x41017fff 0x0  ; init BTCM to 0

    The red marked code causes a bus error. As a result, the rest of the script does not work correctly (the BTCM remains uninitialized).

    I was able to solve the problem by using 32bit accesses, i.e. by inserting %long as format specifier:

    InterCom CR5 data.set 0x41010000--0x41017fff %Long 0x0  ; init BTCM to 0

    I assume (but don't know) that the 32bit accesses are required to initialize the ECC. However if this is really the case, I'm wondering why this was working for you...?

  • +1 in reply to Thomas Dedler
    TI__Mastermind 23395 points

    Hello Thomas,

    Glad that you are able to use the scripts for launching PDK examples.  I've interacted with several other TRACE32 users who also have used these scripts successfully with PDK and other images (AutoSAR frameworks).  The two issue points you report are not ones I've encountered or seen reported before. 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. There is some sensitivity to the system initial state which can trip up any JTAG flow. I recall the CCS related instructions for these only test for 'no-boot' mode. I often use SD/MMC boot settings but with no card inserted and they work for me.

    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.  These settings set the ECC behavior for the TCMs. I suspect your feedback/report about needing %Long is proper if the ECC is enabled but probably doesn't matter otherwise.  This write is happening from the R5 to its own internal memory.

    Your report about issue with "data.Set 0x61000000++0x7fff" is odd.  This command is issued from the Cortex-M3 to a dual port instance of the R5 internal memory.  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.

    One general rule, is your PDK tests and firmware should come from the same SDK drop. If they are mixed and matched there is a very good chance something will not work well. Please make sure you updated all binary paths so they are sourced by the same SDK version.

    My best guess maybe your board has some image in ospi and it ran changing the initial state. This could cause some hiccup in the script as the script is only tested from a couple starting states.

    If you provide the DIP switch settings you are using I could see if I run into the same conditions.  The comment at PG1 relates to what version of the silicon is in use.  There were some M3 and R5 rom code changes across different versions of the chip. These types of differences also could play into why your initial ECC configuration is not what I see.

    I'll update the script to use %Long as that seems fine.  I'll roll that in along with some other changes I made in the last week. I periodically update this in the TI-CDDS portal so if you have access that would be a way to get periodic updates.

    Thanks for the detailed feedback.

    Regards,

    Richard W.

  • 0 in reply to Richard Woodruff
    Intellectual 270 points

    Hello Richard,

    yes, you are right, ECC is activate after reset in my ACTLR. But although I have code in the OSPI, I usually start the processor in NoBoot mode when using the debugger, so this shouldn't be an issue. And yes, I use the firmware from the same SDK (I made this mistake only once some month ago when switching to 07_03_00).

    The ROM version could be a reason for the different behavior. The TRM says, M3 ROM code is bypassed in NoBoot mode... but maybe the R5 ROM code is executed when I start the core with the debugger? According to the info stored at 0x4182FF80, I have the following version:

    Version Number = 1.1.1
    Version Date = 09/21/20 
    Device = j7es

    Thanks again for your help!

    Best regards

    Thomas