TMS570 OpenOCD Flash Support

Sun Nov 20 11:39:19 UTC 2022

Dear Devin Stafford

On Friday 18 of November 2022 19:07:13 Devin Stafford wrote:
> Hope all is well. Thank you for providing the patches and documentation for
> the TMS570 flash support. They have been of great help to me.

that is really pleasing for me, that my old effort in TMS570 area
that partially related to my not so open work under old former group
destroying many of my other investments, has found some user.
But pushing project forward to mainlineable state is big effort.
So I send the CC to RTEMS list where somebody other can have some
experience in this area.

I would personally liked to pour my hands or lead studnet, but until
I finish our ESA project, I am sillent even in more heartily projects
related to RTEMS... Sorry...

  https://gitlab.com/pikron/projects/sumintadc/deliverables

I am keeping only RISC-V and teaching based ones to survive.

> I was able to confirm the functionality of the flash support with your
> patches via XDS100v2 using the TMS570L3137 HDK. I am now trying to use a
> Raspberry Pi to connect to the TMS570L3137 HDK from the RPi's GPIO to the
> TMS570L3137 HDK's external JTAG. I am able to find the JTAG Tap, but I get
> the following error message:
> [image: unsuccessful_old_openocd.png]

Great, the given old GDB version worked well even with FTDI based
adapters as I remember. I can send even technological data for our
JT_USB6 version

  https://pikron.com/pages/products/accessories.html

But XDS1000 standalone adapters from TI are not expensive, so that
can be a better/more accessible choice.

> When I use the same wiring setup and use the latest version of OpenOCD (so
> only debug support for the TMS570 and no flash support), I am able to find
> the TAP, examine the target, and receive no errors.  Here is that output:
> [image: successful_openocd.png]

That is great, that mainline supports TMS570 reliably now. There has been 
problem on big-endian R4 to access memory behind EIM (DRAM) in the
older version if I remember well. I have some hack in my patches, I think

  https://cmp.felk.cvut.cz/~pisa/tms570/openocd-patches/

> I have attached a logic analyzer for both instances, and the signals look
> similar for both.
>
> Therefore, I believe it is a software issue and was wondering if you have
> any advice to resolve this issue? I have attached my openocd.cfg file as
> well.

So to recapitulate, you are trying to use old TMS570 GDB
(working with XDS100v2) with raspberrypi-native JTAG interface
and there is a problem.

The first reported problem (on raspberrypi-native) is
Warn: Invalid ACK 0x6 in JTAG-DP transaction
I would expect, that low level JTAG transport is OK,
a correct part is reported, but the target stays in undefined
state probably. You can try to lower interface frequency
or adjust reset timing. I would expect that there can be
problem with incompatible, other default reset configuration
in old GDB for raspberrypi-native.
Try to look into corersponding
  openocd/scripts/interface/raspberrypi-native.cfg
if that doe snot help, then into interface sources.

Try to check what are mapping and options for reset
related section

# bcm2835gpio_trst_num 7
# reset_config trst_only

# bcm2835gpio_srst_num 24
# reset_config srst_only srst_push_pull

# or if you have both connected,
# reset_config trst_and_srst srst_push_pull

when you compare with

openocd/scripts/interface/ftdi/xds100v2.cfg

#
# Texas Instruments XDS100v2
#
# http://processors.wiki.ti.com/index.php/XDS100#XDS100v2_Features
#

interface ftdi
ftdi_vid_pid 0x0403 0xa6d0 0x0403 0x6010

ftdi_layout_init 0x0038 0x597b
ftdi_layout_signal nTRST -data 0x0010
ftdi_layout_signal nSRST -oe 0x0100
ftdi_layout_signal nEMU_EN -data 0x0020
ftdi_layout_signal nEMU0 -data 0x0040
ftdi_layout_signal nEMU1 -data 0x1000
ftdi_layout_signal PWR_RST -data 0x0800
ftdi_layout_signal LOOPBACK -data 0x4000

echo "\nInfo : to use this adapter you MUST add ``init; ftdi_set_signal 
PWR_RST 1; jtag arp_init'' to the end of your config file!\n"

There are configuration of nTRST, nSRST and PWR_RST signals for FTDI.
Check if equivalent signals are configured correctly for raspberrypi-native.
There can be difference between old and new GDB. Check PWR_RST influence.
Putting some enforced reset into raspberrypi-native could help.

Generally, the right direction is to forget about old GDB version
and make current mainline to support Flash on TMS570. But that
could be really huge project.

There are two main problems. My two patches are based on Andrey Smirnov
series which, as I know, did not reached mainline. There is lot of
work there. May it be, there is already equivalent enhancement included,
but it can be on different basis. needs to analyze understand existing
or add missing functionality.

The other problem are actual Flashing algorithm running on TMS570.
The library is available from TI only in a binary (ELF object archive/lib)
form. Distribution such "firmware" in GDB mainline can be a problem.
One option is to change mechanism to load target fragment from external
ELF file, which would be generic and acceptable for mainline probably.
Other option is to reverse engineer object files and rewrite them in
C or assembly. I do not expect that it is so complex at the end
and could be usesfull for more TMS570 projects.

But generally desired update is lot of work, week, month full time???
Passing through mainline review process even probably longer.

So it is on my table as would be nice but I am able to accept
that it never happens. I have no paid or other satisfying projects
with TMS570 personally and Elektroline.cz (for which I consult)
works with smaller TMS570 chips but due SIL3 project they are
forced to certified tools and no operating system...

I hope to find time test RTEMS on TMS570LS3137 and retest our
LwIP work where I want to help with license and directories cleanup.
Most of my work was at my free time and Premysl Houdek's one
was his school work where he has rights by our contry laws.
So it has almost no connection to left people and former group
work. So I see relicensing of that files to RTEMS as nonproblematic...
So it is only to find time and obtain confirmation from Premysl Houdek
and then cleaning the files locations. Next year hopefully...

Best wishes,

                Pavel Pisa
    phone:      +420 603531357
    e-mail:     pisa at cmp.felk.cvut.cz
    Department of Control Engineering FEE CVUT
    Karlovo namesti 13, 121 35, Prague 2
    university: http://control.fel.cvut.cz/
    personal:   http://cmp.felk.cvut.cz/~pisa
    company:    https://www.pikron.com/
    e-mail:     pisa at pikron.com
    projects:   https://www.openhub.net/accounts/ppisa
    CAN related:http://canbus.pages.fel.cvut.cz/
    RISC-V education: https://comparch.edu.cvut.cz/
    Open Technologies Research Education and Exchange Services
    https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home

-------------- next part --------------
telnet_port 4444
gdb_port 3333

adapter_khz 1500

source [find interface/raspberrypi-native.cfg]
source [find target/ti_tms570.cfg]
#source [find target/ti_tms570ls3137.cfg]

reset_config trst_only
init; jtag arp_init

# Disable Parameter Overlay Module (POM)
# when reset vector is overlaid incorrectly, device hard
# locks after reset
# mww 0xffa04000 0

reset halt
wait_halt
resume
sleep 1000
tms570.cpu arp_halt
wait_halt

tms570.cpu configure -event gdb-attach {
                cortex_r4 dbginit
                reset halt
                wait_halt
                resume
                sleep 1000
                tms570.cpu arp_halt
                wait_halt
}