<Guest3678>
I would like to compile and build firmware for the MAX35103EVKIT2 which includes a 10 pin jtag connector into a MAX32620 Cortex-M4 low-power MCU … will openocd let me do it? What usb to j-tag do you recommend I use? Also, I have IAR project files, can they be imported into openocd?
<Haohmaru>
this is the openocd channel.. openocd generally works with cortex-M4 for sure, not sure about your particular part, and not sure about jtag, the others would know better
<Haohmaru>
as for IAR, what project files? isn't IAR a compiler/toolchain thing?
<Guest3678>
Yes, it is a compiler that builds the firmware file … very old and expensive
<Haohmaru>
what are you trying to do? openocd is typically used to debug and program "chips"
<Guest3678>
I am trying to program a chip
<Guest3678>
Do not care about debugging
<Guest3678>
At least not yet
<Haohmaru>
okay, wait till the PROs wake up
<Guest3678>
This is a replacement firmware for this board so I can extract the data using the serial port (water flow meter kit)
<karlp>
there's some support for the max32xx series, I've no idea how close the max35 series is.
<karlp>
migh tbe close, might.... not :)
<karlp>
usb jtag is very very much up to you, but anything cmsis-dap is pretty easy choice these days.
<karlp>
oh, max32 is hte cpu, not max35, I read that wrong.
<Guest3678>
How do I know if that interface is present on this board? When I connect a cable to the USB port, It does show a “mapped” usb drive by default and it calls it DAPLINK … and it adds serial port as well
<karlp>
daplink sounds like it already works.
<karlp>
try -f itnerface/cmsis-dap.cfg ....
<Haohmaru>
you seem to be lucky then
<karlp>
if IAR supports cmsis-dap, you might be fine to jsut do that too.
<karlp>
no need to get openocd involved at all, if you wanna go and use that old clunker...
<Guest3678>
I am afraid of even installing it
<Haohmaru>
>:)
<karlp>
then don't?
<Guest3678>
I would rather do this from my m2 Mac or a linux box …
<Haohmaru>
linux ftw
<PaulFertser>
Is m2 mac not a linux box?
<karlp>
yeah, manual for that EVm shows it has a an onboard "mbed module" which is this daplink.
<karlp>
you're good to go.
<Guest3678>
So, openocd -f interface/cmsis-dap.cfg -f target/max3260.cfg will be needed …. The rest is learning how to compile and burn the firmware
<PaulFertser>
Guest3678: give it a try now and see
<PaulFertser>
While you got attention of this channel :)
<Guest3678>
On the Mac? I have brew installed and configured
<Guest3678>
Or should I connect it to an ubuntu machiine?
<PaulFertser>
Aren't you supposed to be running Asahi Linux on that mac? ;)
<Guest3678>
Or map it to my windows VM
<PaulFertser>
Doesn't matter, OpenOCD should work the same on all supported OSes.
<Guest3678>
I got tired of waiting for the GPU and got used to the Mac OS
<Guest3678>
My Asahi was dormant for 2 years taking half of my ssd …
<karlp>
(note, you can just use the usb interface, you don't need to get another usb-jtag and use that 10pin header)
<Guest3678>
I wiped it eventually
<Guest3678>
Ok, trying it in the windows VM since it is already showing the mapped drive
<PaulFertser>
Guest3678: no pastes more than two lines to any public channel!
Guest3678 has left #openocd [#openocd]
<PaulFertser>
Guest3678: you sent that mail just an hour ago?
Guest3678 has joined #openocd
<PaulFertser>
Eh all that was meant for Guest72
<PaulFertser>
Guest72: so, you have a soft core on your FPGA, right? When configuring the soft core how did you configure it?
<PaulFertser>
Guest72: what debug interface specifically have you enabled and how exactly?
<PaulFertser>
Guest72: and why do you need to manually specify parameters for ftdi, is it integrated on your board?
<PaulFertser>
Guest72: why does your mail have "Re: [OpenOCD-user] Anyone using STM32U5 with OpenOCD?" subject and has "In-Reply-To: <CWLP265MB42671B1C61B31F1477CB2238BE112@CWLP265MB4267.GBRP265.PROD.OUTLOOK.COM>" ? Is your question related to that thread?
<Haohmaru>
guestoverflow
<Guest3678>
On the Mac, do I need to be in a specific folder after installing openocd
<Guest3678>
at file "embedded:startup.tcl", line 28
<PaulFertser>
Guest3678: and karlp is right, if you have that daplink with mass storage emulation and you just want to flash, probably easier to simply copy the firmware there for automatic flashing.
<PaulFertser>
Guest3678: do not paste please!
<PaulFertser>
Guest3678: 0.12.0 is old, ask brew for --HEAD
<Haohmaru>
Guest3678, if it's installed "in the system folders" then all the "stock" scripts and configs will be found with the relative paths as in the commands they gave you above
<Haohmaru>
thus it shouldn't matter what working dir you're in
<ringo>
I assume I need to be in the root folder where the app is installed
<ringo>
Or that target file is not there
<PaulFertser>
ringo: no, properly installed openocd knows where its scripts are.
<karlp>
target/max32620.cfg
<karlp>
annd max3263x.
<PaulFertser>
You have a typo again, yes, target/max32620.cfg
<karlp>
what part is on the dev board again?
<karlp>
yeah, 32620, you said that yourself in your intro :)
<ringo>
Sorry … you are right … max32620.cfg actually reads the file … moving the cable to the max now
<ringo>
*mac
<Haohmaru>
btw, on linux (at least on debian) the normal user by default can't access USB ports (e.g. a SWD debugger) and stuff, so you have to add your user to a group first
<ringo>
Info : [max32620.cpu] Cortex-M4 r0p1 processor detected
<Haohmaru>
nice
<ringo>
Info : starting gdb server for max32620.cpu on 3333
<ringo>
Info : Listening on port 3333 for gdb connections
<ringo>
nice!!!!
<ringo>
I wanted to just burn firmware …. Now, I can modify it and debug it as well
<Haohmaru>
i can show you my silly .sh script for mere flashing a .elf if you want
<ringo>
Yes, please do … I am very new at this
<PaulFertser>
If you meet Kevin Gillespie <kgills> somewhere don't forget to say thanks for the driver :)
<ringo>
How do I compile the firmware file? Openocd will also do that?
<ringo>
Perhaps next fosdem!
<Haohmaru>
no, openocd isn't a compiler
<karlp>
it came straight from kgills' maxim email...
<PaulFertser>
ringo: no script needed, use -c "program your.elf verify exit"
<ringo>
Ok, so, I can debug and flash firmware using openocd …. How do I debug, is there a tutorial I can follow … I do not want to impose on anyway here to teach me ;)
<karlp>
interface, target, and program, nothing else needed.
<PaulFertser>
break main; run can be replace by single "start".
<ringo>
Excellent …
<ringo>
What do you recommend I use as a compiler?
<Haohmaru>
gcc ;P~
<ringo>
The application note only gives me sources … no elf
<Haohmaru>
if the code was written for IAR, it may need to be butchered till it works on another compiler
<ringo>
IAR is the only project file they include … it is only 3 .c files … but it uses the board folder with the max32620 stuff which I assume is specific to IAR
<karlp>
have fun, ultrasonic flow metering is super non-trivial.
<ringo>
Directly on the same unit …. And step 3 is to 3D print a version that clips on the pipe
<ringo>
Luckily, the science part is the easy part for me … Ph.D. in physics … superconductivity
<PaulFertser>
Applying theory to be practical is a whole different topic though ;)
<ringo>
Experimental physics is what I did :)
<karlp>
like I said, have fun :)
<karlp>
I have an ex colleague doing a startup in this, and at an old job we used some commercial US flow meters, but it's suuuuper picky.
Guest78 has joined #openocd
<ringo>
Anyway … this is a hobby project … it will be months before I reach step 3 … I am just happy I can now reprogram this board and get the data out
<karlp>
doing it for garden sprinklers with dirty pipes with bubbles and all sorts of cavitation.... goooood luck ;)
<karlp>
well, I don't know if you're doing sprinklers, but the ev kit talked about that use case.
<ringo>
I am not … this is for a water well filtration system (my house) … goal is to remove hardness and disinfect without harsh chemicals … only peroxide …
<PaulFertser>
Would ultrasonic flow metering work with a superfluidity system?
<ringo>
It will not even see it at those frequencies
<PaulFertser>
BTW, did you enjoy the hype about LK-99 or what was your emotional reaction? Guess people around you were asking about it every day.
<ringo>
I told everyone who asked it was a hoax from day 1
<ringo>
I worked with high temperature superconductors from 1986 to 1997 … and high temperature still meant 77 to 120K
<PaulFertser>
On a positive side while everyone was interested it was an opportunity to teach people real science.
<ringo>
They have made little progress since then … up to 150K perhaps 180K … BTW: room temperature is 273K
<PaulFertser>
I mean not the science itself but about how it normally happens, what it involves, what were the recent real advances, stuff like that.
<ringo>
Which is measured from absolute zero ...
<PaulFertser>
:)
<ringo>
Anyway … did not mean to hijack the channel with science talk … :) … will be hanging around though … time to get ready for my day job … woke up at 5:30am obsessed with finding a solution to my metering needs
Guest78 is now known as satelite
<PaulFertser>
I'm not talking much with "common people". Is that not known to the majority?
<PaulFertser>
ringo: this channel can tolerate some offtopic, no problem :)
<PaulFertser>
It's always inspirational to learn what cool things other people do.
<PaulFertser>
Can't resist from nit picking, 273.15 K is 0 C, so some 20-25 K below _room_ temperature ;)
<ringo>
Not if you live in north Alaska ;)
<PaulFertser>
:D
<karlp>
depend what time of year ;)
<karlp>
it's quite pleasant in july....
satelite has quit [Quit: Client closed]
Guest72 has quit [Quit: Client closed]
Guest72 has joined #openocd
<Guest72>
Hey, my bad about the paste
<Guest72>
i sent the email last week and repeated it today
<Guest72>
my question is not related to the other thread. I wanted to copy the senders and mistakenly also copied the subject
<Guest72>
PaulFertser: what do you mean whit how did I configure the soft core? related to what especifically?
Guest72 is now known as eliasph88
<eliasph88>
PaulFertserI enabled the JTAG interface
<eliasph88>
PaulFertser: yes, the Alveo u280 Xilinx board has a FTDI device integrates (FT42532HQ USB-JTAG/UART Interface)
eliasph88 has quit [Quit: Client closed]
eliasph88 has joined #openocd
eliasph88 has quit [Client Quit]
eliasph88 has joined #openocd
<PaulFertser>
eliasph88: if it's a softcore then there must be different ways to enable OCD in it.
<PaulFertser>
eliasph88: how does it normally interact with FPGA JTAG?
<eliasph88>
normally, as it is a Xilinx device, it uses Xilinx xsct tool
<PaulFertser>
But you want to have debug connection to the softcore, right?
<eliasph88>
right
<PaulFertser>
So the softcore must have some configuration for that.
<PaulFertser>
And it must be somehow hooked to the FPGA JTAG facilities.
<eliasph88>
other members of the team have successfully use OpenOCD already with this same softcore
<PaulFertser>
And what was on the other side of remote bitbang?
<eliasph88>
I´m sorry still trying to figure out this. But I thought that this opened a "virtual" connection to the core and they simply sent parameters. Am I wrong?
<eliasph88>
asking them in the meanwhile anyway
<eliasph88>
*parameters = commands
<PaulFertser>
I do not know how that simulation worked.
<PaulFertser>
And how is the OCD part of the softcore supposed to be connected to physical JTAG.
<eliasph88>
ok i do not know if this is what you're asking but the physical connection is through the xilinx bscan chain and with a bscan to Jtag converter
<PaulFertser>
What does it mean in JTAG terms? Is another TAP added to the chain or what?
<eliasph88>
exactly
<eliasph88>
sorry I though that the message was still here
<eliasph88>
yes is a daysi chain with 2 devices: 1 the FPGA (which has another two, one for programming it and another for the ILA) and another TAP for a JTAG device inside our softcore
<eliasph88>
for Xilinx is recognizes as device 1 the FPGA, ID=14b7d093, which is also recognize a the specific board and in the device 4 the ID of our TAP for the softcore b1aaa07d
<PaulFertser>
I have asked you to never paste to a channel more than two lines :(
<eliasph88>
my bad, how should I sow the full autodetection output from OpenOCD as you requested then? I kept as small as I could
<PaulFertser>
Paste elsewhere and show a link here.
<eliasph88>
ok
<eliasph88>
it is deletable?
<PaulFertser>
Not on IRC. So in that xilinx tool can you show something which lists the TAPs along with their IR lengths?
<PaulFertser>
And for OpenOCD can you please do a paste without any target specified at all? When t says "expected 1 of 1" it means some taps were specified in config.
<PaulFertser>
OK, that I can see. Now please show data from the xilinx tool along with IR lengths. And from OpenOCD where just autodetection is involved.
<PaulFertser>
Without any taps specified.
<eliasph88>
ok xilinx info updated in the same link at the bottom
<PaulFertser>
eliasph88: I see just one TAP there?
<PaulFertser>
Or is that two, both with irlen 18 ?
<PaulFertser>
On same chain?
<eliasph88>
both TAPs with IR Length 18, different ID Codes
<eliasph88>
in the same chain yes
<PaulFertser>
OK, let's compare to full autodetection now.
<eliasph88>
give a sec to program the FPGA
<eliasph88>
please
Guest35 has joined #openocd
Guest35 has quit [Client Quit]
eliasph17 has joined #openocd
<eliasph17>
ok got it
<eliasph17>
but is to big
<eliasph17>
same lines as before then
<eliasph17>
but if you need some others let me know
eliasph88 has quit [Ping timeout: 250 seconds]
<PaulFertser>
eliasph17: just do without debug and paste full output please.
<eliasph17>
updated again in the same link
<eliasph17>
ok
<eliasph17>
done and updated
<PaulFertser>
Are you sure that xilinx output telling you there was two 18-bit long taps on the chain was taken with exactly the same FPGA configuration (flash contents) that OpenOCD autodetection?
<eliasph17>
is the exact same bitstream, is the question because OpenOCD says irlen 2?
<PaulFertser>
eliasph17: hm, probably autodetection isn't working due to some nonstandard behaviour of this target. Please add to that OpenOCD output where you actually specify two taps both with 18 bit irlen.
eliasph88 has joined #openocd
eliasph17 has quit [Ping timeout: 250 seconds]
<PaulFertser>
eliasph17: hm, probably autodetection isn't working due to some nonstandard behaviour of this target. Please add to that OpenOCD output where you actually specify two taps both with 18 bit irlen.
<eliasph88>
done at the end of the link
<eliasph88>
n,
<PaulFertser>
Probably the xilinx tool does something extra? Like a command to the first tap that somehow enables the second? Or probably there's a line that the FPGA checks on power on and doesn't load configuration at all if it's not right?
<PaulFertser>
Because the chain certainly differs.
<eliasph88>
that makes sense
<eliasph88>
but
<PaulFertser>
Or probably you misinterpret xilinx output and it's showing you some emulated chain.
<eliasph88>
why it does work for the simulation command
<PaulFertser>
It doesn't. For teh siimulaton you define just a single tap so it certainly doesn't match what you tell about the jtag chain.
<eliasph88>
ok, i´ll recheck with them
<eliasph88>
thanks a lot for your time
<PaulFertser>
I hope you figure it out eventually.
<PaulFertser>
That really needs some help from the FPGA devs.
<eliasph88>
Yep, I agree, let see if I can get in touch with someone has travel the same path
<eliasph88>
Thanks anyway for devoting this time to help
<PaulFertser>
This bscan "tunnel" thing is certainly not just another TAP in the chain.
<PaulFertser>
And it depends a lot on what the other devs implemented on the FPGA side.
<eliasph88>
yes I agree. I though that i was doing something bad in the ftdi layout or nRST
<PaulFertser>
So there're different ways to make it, one is via bscan tunnel but then you need to enable it with all the right parameters, another is by mapping instructions with "riscv set_ir" and none of that creates another real tap on the chain.
<PaulFertser>
nRST you can just probe externally to be sure
<eliasph88>
is there a link where I can check this nRST
<eliasph88>
?
<PaulFertser>
eliasph88: check physically with a voltmeter or oscilloscope :)
<eliasph88>
ohh. thanks not possible in my case but sure is an option
<PaulFertser>
Why not possible how come?
<eliasph88>
the FPGA is inside an inaccessible cluster
<PaulFertser>
Well do you at least have access to schematics? :)
<PaulFertser>
Just set nRST ftdi line to not be driven at all.
<PaulFertser>
For that default ftdi_layout values used on breakout boards without any RST line controls work.
<eliasph88>
well I'll try it then
<eliasph88>
this I can do
<PaulFertser>
eliasph88: "ftdi layout_init 0x0008 0x000b" should be right unless nRST is pulled low by a pulldown :)
<PaulFertser>
eliasph88: as by default OpenOCD just uses that layout and doesn't touch nRST signal at all.
<eliasph88>
-c "ftdi layout_init 0x0008 0x000b" -c "ftdi layout_signal nSRST -data 0x0020 -oe 0x0020" is what I am using
<eliasph88>
but in any case if wrong OpenOCD wont be seeing the FPGA device neither
<PaulFertser>
I wouldn't specify nSRST at all.
<PaulFertser>
I have an impression your FPGA buddies have forgotten to tell you esential details about how they connected the RISCV softcore OCD module.
<PaulFertser>
Because "we used BSCAN" is not a full answer.
<eliasph88>
ok, I won't specify it then
<eliasph88>
I'll definetely talk with them
eliasph88 has quit [Quit: Client closed]
Haohmaru has quit [Quit: saionara]
xantoz_ is now known as xantoz
nerozero has quit [Ping timeout: 256 seconds]
damex has quit [Quit: No Ping reply in 180 seconds.]