• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 99 subscribers
  • Views 563 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: R5F MCU0 disconnects when Board_Init function is executed

Mehmet Onur Cirit
Prodigy 35 points
Part Number: TDA4VM

We are working on a custom board that is designed by our customer based on Jacinto 7. More specifically, we are working on an MCU domain R5F on TDA4.

The customer provided an initial demo that can be built with their custom build system. We integrated all of the provided files to our own build system and as far as we can see the issued compile/link commands are basically the same. When we load the customer binary it works just fine, however, when we load our own binary, the board fails inside Board_init() function while trying to execute Board_PLLInitMcu(). Also, the debugger disconnects from the R5F core emitting the following error in the log. Only when we power cycle the board we can connect the R5F core again.

MCU_Cortex_R5_0: Trouble Setting Breakpoint with the Action "Finish Auto Run" at 0x97063eb0: (Error -1065 @ 0x0) Unable to access device memory. Verify that the memory address is in valid memory. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Breakpoint Manager: Retrying with a AET breakpoint
MCU_Cortex_R5_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032) 
MCU_Cortex_R5_0: Unable to determine target status after 20 attempts

Is there an educated guess of what might be going wrong in this case and is there any suggestion on how we can proceed with the debugging? Maybe a way to avoid locking the core or a way to reconnect the core so that we can inspect the stack frame.

  • 0
    TI__Mastermind 42135 points

    Hi Mehmet,

    Is there any modification done in Board_PLLInitMcu()?

    Also, can you please verify that system firmware is loading properly?

    Regards,

    Parth

  • 0 in reply to Parth Nagpal
    Prodigy 35 points

    Hello Parth,

    Thanks for the reply.

    We are using SDK version 7.2 with the following post-release patch.

    psdk_rtos_j721e_es11_src.tar.gz

    This patch includes board_pll.c (defines Board_PLLInitMcu) which we did not modify in any way.

    For the verification of system firmware do you mean that the firmware loaded into DMSC core? We are using a ccxml file for launching the board which executes J721E.gel initialization script. This script works fine for the customer software therefore I don't think there is a problem with that. If you meant anything else, could you please elaborate? Also, how do we verify this system firmware?

    Thanks and regards.

  • 0 in reply to Mehmet Onur Cirit
    TI__Mastermind 42135 points

    Hi Mehmet,

    Can you please share the code snippet from where exactly the failure occurs?
    Also, can you please share the build procedure you are using to build the application?

    Regards,
    Parth

  • 0 in reply to Parth Nagpal
    Prodigy 20 points

    Hello Parth,

    Thanks for your interest and question. I would like to share s fileshare link which contains a video record that shows our issues while debugging Board_PLLInitMcu function.

    Link: https://fs.tttech.com/index.php/s/jRtzwkaCONTP2dg
    Pass: tttechtn

    Regards,

  • 0
    Prodigy 35 points

    Hello again,

    We tracked our problem down to a configuration array that reside in non-initialized .bss memory. The following variable is located inside devices.c file of SciClient module. As seen in the code snippet it is mapped to .bss.devgroup.MAIN.

    static struct lpsc_module j721e_j7_main_psc_wrap_main_0_modules[ARRAY_SIZE(j721e_j7_main_psc_wrap_main_0_mod_data)] __attribute__((__section__(".bss.devgroup.MAIN")));

    When we connect to R5F core and load our code, we observe that this configuration array is filled with 0xFF bytes. Unlike ours, when we load the customer program this memory area is filled with 0x00 bytes. When the array is filled with 0xFF bytes somewhere at post_init section of psc initialization we are getting disconnected because the module confuses a power domain to be enabled where it was actually not.

    Now, our problem boils down to initialize this non-initialized memory with 0x00 bytes, of course exclusively during initial boot. We are using the same linker definition file with our customer and the related section definition is as shown below.

    MEMORY
{
  OCMCRAM_Common : ORIGIN = 0x41C3F000 , LENGTH = 0x0000C000 /* 48 KiB */
  OCMCRAM_Common_NonCache : ORIGIN = 0x41C4B000 , LENGTH = 0x00000400 /* 1024 Byte */
  OCMCRAM_Core0 : ORIGIN = 0x41C4B400 , LENGTH = 0x00000400 /* 1024 Byte */
  OCMCRAM_Core1 : ORIGIN = 0x41C4B800 , LENGTH = 0x00000400 /* 1024 Byte */
  OCMCRAM_Core2 : ORIGIN = 0x41C4BC00 , LENGTH = 0x00000400 /* 1024 Byte */
  OCMCRAM_Core3 : ORIGIN = 0x41C4C000 , LENGTH = 0x00000400 /* 1024 Byte */
  OCMCRAM_Core4 : ORIGIN = 0x41C4C400 , LENGTH = 0x00000400 /* 1024 Byte */
  OCMCRAM_Core5 : ORIGIN = 0x41C4C800 , LENGTH = 0x00000400 /* 1024 Byte */
  MCU0_DDR : ORIGIN = 0xA0100400 , LENGTH = 0x00EFFC00 /* 15 MiB */
  APP_LOG_MEM0 : ORIGIN = 0xAC000000 , LENGTH = 0x00040000 /* 256 KiB */
}

SECTIONS
{
  <other sections>
  
  .TI_sysfw_sections_bss_devgroup : ALIGN(4)
  {
    _TI_sysfw_sections_bss_devgroup_START = .;
    *(.boardcfg_data)
    *(.data_user)
    *(.bss.devgroup.DMSC_INTERNAL)
    *(.bss.devgroup.MAIN)
    *(.bss.devgroup.MCU_WAKEUP)
    . = ALIGN(4);
    _TI_sysfw_sections_bss_devgroup_END = . - 1;
    _TI_sysfw_sections_bss_devgroup_LIMIT = .;
  } > MCU0_DDR
  
  <other sections>
}

    Although, we use the same ld file (only difference is that memory sections are shifted in DDR) and also almost the same options our map file outputs are slightly different.

    /* Customer .map file */

.TI_sysfw_sections_bss_devgroup 
*          0    a01aa200    00002800     
                  a01aa200    00001700     sciclient_direct.aer5f : sciclient_boardcfg.oer5f (.boardcfg_data:init)
                  a01ab900    00000004     rm_pm_hal.aer5f : devices.oer5f (.bss.devgroup.DMSC_INTERNAL) [fill = 0]
                  a01ab904    00000f14                     : devices.oer5f (.bss.devgroup.MAIN) [fill = 0]
                  a01ac818    000001e8                     : devices.oer5f (.bss.devgroup.MCU_WAKEUP) [fill = 0]

    		 

    /* Our .map file */

.TI_sysfw_sections_bss_devgroup 
*          0    97123a80    00002800     UNINITIALIZED
                  97123a80    00001700     sciclient_direct.aer5f : sciclient_boardcfg.oer5f (.boardcfg_data:init)
                  97125180    00000004     rm_pm_hal.aer5f : devices.oer5f (.bss.devgroup.DMSC_INTERNAL)
                  97125184    00000f14                     : devices.oer5f (.bss.devgroup.MAIN)
                  97126098    000001e8                     : devices.oer5f (.bss.devgroup.MCU_WAKEUP)

    Their map file has "[fill = 0]" appended at the end of their section names but ours does not. The linking options that we and the customer are using are listed in the table below.

    Customer Command Our Command
    -stack 0x400
    -heap 0x10
    -e=brsStartupEntry 
    -a
    --warn_sections
    --unused_section_elimination=on
    --cinit_compression=rle
    --compress_dwarf=on
    --copy_compression=rle
    -scanlibs
    --reread_libs
    --display_error_number  
    --diag_suppress=10068
    linkercommand.ld    		 -stack 0x400
    -heap 0x10
    -e=brsStartupEntry
    -a
    --warn_sections
    --unused_section_elimination=on
    --cinit_compression=rle
    --compress_dwarf=on
    --copy_compression=rle
    -scanlibs
    --reread_libs
    --display_error_number
    --diag_suppress=10068
    -l linkercommand.ld
  • 0 in reply to Mehmet Onur Cirit
    TI__Mastermind 42135 points

    Hi,

    Apologies for delayed response. 

    Mehmet Onur Cirit said:
    Now, our problem boils down to initialize this non-initialized memory with 0x00 bytes,

    You can refer to user guide https://www.ti.com/lit/ug/spnu118y/spnu118y.pdf?ts=1638438071505&ref_url=https%253A%252F%252Fwww.ti.com%252Ftool%252FARM-CGT. This user guide describes multiple ways to initialize the non-initialized memory.

    Regards,
    Parth

  • 0
    Prodigy 35 points

    Hello again Parth,

    We already knew and tried the initialization methods that you referred to.

    The problem was resolved by using --ram_model linking option. We realized that the customer map file did not have .cinit section which led us to use this linking option. It is still confusing because neither the customer nor we are using any memory model linking option and by default, it is specified to be --rom_model in the documents. We have also checked the shorter options -c and -cr, and verified that they are also not present in the customer linker options.

    We are still looking for a concrete explanation as to why this section is not initialized with 0 values when we use the --rom_model option. In 8.5.11.2 section of the document that you referred to, it is specified that the .bss sections become holes when they are grouped with initialized sections. We are using fill value as 0 and the holes must be filled with zeroes. If you check our map file, the group TI_sysfw_sections_bss_devgroup includes .boardcfg_data:init (which is initialized) and other uninitialized bss sections. In this case, our .bss sections must be filled with zeroes as per specification but they do not. Do you have any comments on that?

  • 0 in reply to Mehmet Onur Cirit
    TI__Mastermind 42135 points

    Hi Mehmet,

    Mehmet Onur Cirit said:
    It is still confusing because neither the customer nor we are using any memory model linking option and by default, it is specified to be --rom_model in the documents. We have also checked the shorter options -c and -cr, and verified that they are also not present in the customer linker options.

    There should be some difference between customer's build environment and yours. Can you please share the complete build logs from customer application and your application?

    Regards,
    Parth