• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 475 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.

TDA4VE-Q1: OSPI Trace32 flashing HS version

Kordian
Prodigy 10 points
Part Number: TDA4VE-Q1
Other Parts Discussed in Thread: DRA829, UNIFLASH

Tool/software:

We are utilizing a custom board with J721E SR1.1 HS-FS on SDK 10.0.0.5. We are attempting to flash OSPI using TRACE32 with the dra82x-ospi-MT35XU512-snor.cmm script, but we are encountering some issues. Are there any prerequisites required to flash the HS version using TRACE32?

We have tested the flashing script on an EVM board with the GP version, and we are able to flash only when bare-metal is enabled. According to the comments in the provided script, bare-metal is only necessary when R5 is not yet booted, but it does not work when disabled.

IF COMBIPROBE()||UTRACE()
   SYStem.CONFIG.CONNECTOR MIPI34 ; because of converter LA-3782
 
&use_pll2="yes"
&bare_metal="yes"              ; if R5 is not yet booted say yes
&iprobe="no"                   ; if TRACE32 logic analyzer hooked to r306 on SOM
&program="yes"                  ; write to flash
 
IF "&iprobe"=="yes"
(
   NAME.RESET
   NAME.SET IProbe.00 FREQ
   IProbe.CSELect.IProbe FREQ     ; display ospi0_clk
   IProbe.Timing.IProbe.FREQ
   iprobe
   iprobe.off
)
 
IF "&bare_metal"=="yes"
(
   ; call out to bare metal CMMs to setup clocks 
   TITLE "TRACE32 for ARM-CM3 - MASTER"
   DO "~~/cmm-ti/cmm-dra/cmm-tda4_dra829/x_gel_to_cmm_public/j7es_m3.cmm"
   register
   DO "~~/cmm-ti/cmm-dra/cmm-tda4_dra829/x_gel_to_cmm_public/J721E.cmm"
   wait 1s
)


Regarding our custom board, flashing using UNIFLASH works fine, and we are able to boot. However, flashing using T32 fails. My guess is that due to the locked M3 JTAG on the HS version, there is no option to set clocks via the j7es_m3.cmm script, which is required for bare-metal flashing.


Evalboard registers visible and changing
(EVM board with GP: When forcing M3 Power & clock, active registers are visible and changing.)


HS custom board
(Custom board with HS: After forcing, register values go from 0x23000000 to ???)

Based on these observations, is it possible to flash the HS version using T32? Does this process require unlocking the JTAG for M3, or is there another solution to address the non bare-metal flashing issue?

  • 0
    TI__Guru 63780 points

    Hi,

    It’s a long weekend, so kindly expect a response early next week.

    Best Regards,
    Sudheer

  • 0 in reply to Doredla Sudheer Kumar
    TI__Mastermind 38670 points

    Hi,

     Have you tried unlocking JTAG before flashing to see if it works?

    For HS device, for JTAG access, you will need to unlock the JTAG. But I will confirm once on my end as well if this is something required with T32.

    Regards,
    Tanmay

  • 0 in reply to Tanmay Patil
    Prodigy 10 points

    Hi

    I am relatively new to security-related topics and have not yet attempted to unlock JTAG for the M3. Recently, I came across a post stating,
    "The M3 core on J7ES HS devices cannot be unlocked in a functional boot mode." TDA4VM: secure jtag （lauterbach）

    We have been successfully flashing the EVM GP board in OSPI boot mode and want to replicate this process on the HS board so switching to non-boot mode -> unlocking M3 JTAG and flashing each time I think defeats the purpose of using T32 scripts for easier flashing. 

    Best Regards,
    Kordian

  • 0 in reply to Tanmay Patil
    Prodigy 10 points

    Hi,

    Have you managed to verified if any additional requirements are needed for T32 flashing on the HS version?

  • 0 in reply to Kordian
    TI__Mastermind 38670 points

    Hi Kordian,

    Apologies for the delay.

    Can you see section 4 "HS Device Flashing With OSPI Memory Boot Mode Only" In the document https://www.ti.com/lit/an/spracz6/spracz6.pdf?ts=1746522328699&ref_url=https%253A%252F%252Fwww.bing.com%252F

    Kordian said:
    HS board so switching to non-boot mode -> unlocking M3 JTAG and flashing each time I think defeats the purpose of using T32 scripts for easier flashing. 

    HS devices are not really supposed to be used with a debugger. T32 is meant to debug on GP devices and the binaries can then be used with HS devices. That is the default flow. The device is also less secure if debugger can be used with HS devices.

    Regards,
    Tanmay

  • 0 in reply to Tanmay Patil
    Prodigy 10 points

    Hi

    Thanks for clarification.

    I have one more question regarding the bare metal option in the script. By default, this option is enabled, and based on the comment, it appears to be necessary only if "R5 is not yet booted." Are there any prerequisites for flashing without this option or it should be left always on? Despite R5 being booted on the GP EVM board, the flashing process still fails during our tests (reading the chip ID fails, and the FLASH.ReProgram off operation hangs).

    Best Regards,
    Kordian

  • 0 in reply to Kordian
    TI__Mastermind 38670 points

    Hi Kordian,

    I will forward this thread to our lauterbach expert to answer the questions abot script.

    Regards,
    Tanmay

  • 0 in reply to Tanmay Patil
    Prodigy 10 points

    Hi Tanmay,

    Any update about lauterbach scripts? 

  • 0 in reply to Kordian
    TI__Mastermind 23455 points

    Hello,

    -0-

    It is possible to burn on either a GP or HS device using the TRACE32 flasher.   The typical way to use the scripts is in a non-functional boot mode.  That would be "NO-BOOT" for GP (set via boot mode switches) or via on HS using 'WIR" mode which is set by driving EMU0=0 across a power on reset.   The current flashing script has a call out parameter which takes the parameter HS:FS or HS:SE.  When the device is an HS this parameter will be used to unlock the part to allow scripts to fully run.  On a GP device the parameter is not used as it run time can tell its not an HS.   If you have an SE device a certificate is needed to unlock the device but that is not needed for a GP.  The unlock script will attempt to use the debugger to overdrive the EMU0 pin to ensure a clean 'no boot' start startup.

    I've attached current J7ES scripts which work on GP or HS. The bundle is encrypted with passwd of "TRACE32"

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

    -1-
    If you skip the baremetal and just try and run from an initialized R5, it is your responsibility to ensure all the clocks and flash timings are proper!   The flashing code assumes a 'clean' initial state.  If some other code has programmed the flash controller registers these simple scripts will not comprehend that and the script likely will fail.   It is 'far' easier and safer to startup in a no-boot state (gp-noboot, hs-wir) as the flashing will always work.  It may or may not work depending on initial state from a booted mode.  Imagine if code set the RAT mappings to some other address space every write would be an abort or .... the script cannot undue any possible previous code execution.
    -2-
    TRACE32 also has a ~slow BSDL based flash burner.  This can be a good fall back but its really slow.  Its only good for small images.  The controller flasher (used above) is OK for mid sized images.   If you need to burn things like huge EMMC root filesystems its best to use bigger software like u-boot or some kernel.  JTAG shifting will be dramatically slower then a fast USB link which can use all of DDR for buffers.
    Regards,
    Richard W.