NishanthMenon changed the topic of #openocd to: this is the place to discuss all things OpenOCD | Logs: https://libera.irclog.whitequark.org/openocd/
Guest92 has quit [Ping timeout: 256 seconds]
tsal has quit [Ping timeout: 252 seconds]
tsal has joined #openocd
Hawk777 has joined #openocd
Bertl_oO is now known as Bertl_zZ
nerozero has joined #openocd
sbach has quit [Read error: Connection reset by peer]
sbach has joined #openocd
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #openocd
Hawk777 has quit [Quit: Leaving.]
Haohmaru has joined #openocd
tsal has quit [Ping timeout: 240 seconds]
tsal has joined #openocd
Bertl_zZ is now known as Bertl
Guest92 has joined #openocd
<Guest92> PaulFertser if you are around and have a little spare time ive made some progress.  here is the log when using telnet to halt https://pastebin.com/7q7tJz16    but here is my log when attempting to flash  https://pastebin.com/DXVUX8Bz
<PaulFertser> Guest92: what did you change to make the progress?
<PaulFertser> Guest92: your new first paste looks indeed really good.
<Guest92>  its likely going to seem obvious thing to do but i simply connected VPU to 3.3v and changed buspirate_vreg 1  and
<Guest92> buspirate_mode normal
<PaulFertser> Guest92: hm, if I was more familiar with buspirate I could have guessed.
<PaulFertser> But you already had vreg 1 for the last tries.
<PaulFertser> And mode normal too.
<PaulFertser> So it was just connecting VPU to 3.3 V? From the target or the BP itself?
<PaulFertser> Guest92: please show -d3 log from just starting openocd without trying to program.
<Guest92> i started the .cfg from scrach to ensure i wasnt messing it up
<Guest92> i connected vpu form the buspirate to the VDD on the target
<PaulFertser> Guest92: and "flash info 0" command from telnet please.
<Guest92> ok
<PaulFertser> I have no idea what that VPU pin is for...
<PaulFertser> They say http://dangerousprototypes.com/docs/Bus_Pirate_JTAG_connections_for_OpenOCD VPU isn't necessary if vreg is 1.
<Guest92> when using "openocd -f interface/buspirate.cfg -f target/at91sam7sx.cfg"   the log just keeps coming and coming, i guess this isnt what you need a pastebin of
<Guest92> openocd -d3 -f interface/buspirate.cfg -f target/at91sam7sx.cfg
<Guest92> PaultFertser this is the log from telnet https://pastebin.com/s2336XUm
<PaulFertser> Guest92: yeah, cool, so you need to add 0x00100000 to your "program" arguments after the binary filename.
<Guest92> like so "openocd -f interface/buspirate.cfg -f board/atmel_at91sam7s-ek.cfg -c "program AT91SAM7s256.bin 0X00100000 verify reset exit" "
<Haohmaru> possibly lowercase x there
<PaulFertser> Guest92: yes, about that. Probably this offset argument should come last, I'm not sure. So what are you getting?
Guest2711 has joined #openocd
Boban has joined #openocd
emeb has joined #openocd
PaulFertser has quit [Ping timeout: 245 seconds]
PaulFertser has joined #openocd
nvmd has joined #openocd
<PaulFertser> Guest92: ping
nvmd has quit [Quit: WeeChat 3.4.1]
<Guest92> im back to square one PaulFertser, im puzzled as to what is going on.   i changed nothing since that 1st log today, but upon trying again after the failed write im getting the same issues as yesterday. the 1st succefull connection it stated "embedded ice 0, the 2nd attempt the embedded ice was 15 then on a reboot of eveything its back to 0 like
<Guest92> yesterday
<PaulFertser> Guest92: probably time to erase it by using that extra pin once again?
<Guest92> i thought that as it did attempt to write something, but no change.  im going to try again but leave it connected a little longer
<PaulFertser> Guest92: sometimes adding more gnd wires between debugger and target helps.
<PaulFertser> Guest92: or if you're using cheap/bad connectors it might be a faulty connection somewhere.
<PaulFertser> Guest92: if you get all those extra auto taps again then it likely means TDI is poorly connected.
<PaulFertser> Guest92: do you have an oscilloscope?
<PaulFertser> Guest92: you were so close with that "flash info 0" output state!
<Guest92> PaulFertser i am connecting direct to the points with my cable which is only around 6", i have checked them many times including with a multimeter on the reverse to ensure a good connection has been made.     i have a cheap portable oscilloscope, im not to good with it but if you tell me what im checking and looking for i should be able to
<Guest92> figure it out
<Guest92> ive been focused on the buspirate as its usually universal, but i do have a altera usb blaster if you know if that would be a better option?
<karlp> urh, yeah, much.
<karlp> you can use normal current openocd, instead of some weird private fork.
<Guest92> i was afraid i was ignoring an easier alternative but had got fixated on the BP, im going to wire up the usb blaster.   i guess i can use the complied version on openocd site
<karlp> yup
Haohmaru has quit []
nerozero has quit [Ping timeout: 252 seconds]
<PaulFertser> karlp: weird private fork is just openocd built for cygwin.
<karlp> but also quite old...
<PaulFertser> Guest92: so have you managed to reproduce flash info 0 output we saw earlier?
<PaulFertser> karlp: yes, but it's likely to be able to get the job done.
<karlp> I thought from the logs it was also one that had added some form of special bus pirate support
<karlp> if not, then no matter.
<karlp> if not, what ws wrong with the normal windows builds as is?
<PaulFertser> That special support is just Cygwin emulation which makes POSIX-specific serial code work on Windows.
<Guest92> i did not manage to get it to halt again, i redid the wiring several times and left the erase jumper on for around 3 mins and messed with the .cfg but nothing :(  .  i have wired up the usb blaster in hopes its an issue with the BP itself.  i have hit another likely simple hurdle but i have no clue, for the NRST pin on the target do i connect
<Guest92> nsrst or ntrst from the usb blaster
<Guest92> karlp the normal version when i attempted to use the BP stated "the specified debug interface not found"
<PaulFertser> Guest92: nsrst
<Guest92> thank you PaulFertser
<Guest92> PaulFertser i guess as im powering the target separately i only need to connect TCK TMS TDI TDO NSRT and GND,  vcc and vsup can remain floating?
<PaulFertser> Guest92: target's Vcc must be connected to JTAG adapter's Vtref
<Guest92> Thanks again :)
<PaulFertser> Guest92: Vsupply should probably be left unconnected.
<PaulFertser> nSRST to target's nRST
<Guest92> ok
<PaulFertser> Guest92: probably for reliable operation the erase pin should be connected to GND or Vcc?
<PaulFertser> Guest92: are you leaving it floating while trying to JTAG?
<Guest92> i was leaving it floating, i believe gnd is write locked and vcc is erase
<PaulFertser> Guest92: floating for an input pin is rarely an option.
<PaulFertser> I see the datasheet says it has an integrated pull-down so leaving it unconnected should be fine.
<PaulFertser> For normal operation.
<PaulFertser> I checked the datasheet for you.
<Guest92> thank you for clarifying that, i really do appreciate the help you have given:)
<PaulFertser> I'm eagerly waiting for the results
<Guest92> :)   i have tried to switch over to the usb blaster but im hitting another stumble:/   https://pastebin.com/Q2bDc4PR
<PaulFertser> Guest92: for usb blaster I recommend you use native openocd build (not cygwin!) and zadig to install winusb.
<PaulFertser> Guest92: see README.Windows
<Guest92> i am using the latest compiled version from the openocd site
<PaulFertser> Guest92: ok, then you just need to use Zadig to install winusb for the device.
<Guest92> done:)
<Guest92> i guess its the same commands as the BP but obviously changing to the usb-blaste.cfg
<PaulFertser> Guest92: no changes to usb-blaster.cfg should be made
<Guest92> i have left usb-baster.cfg all as original, command: "openocd -f /interface/altera-usb-blaster.cfg -f target/at91sam7sx.cfg"  gets me https://pastebin.com/4gyuUSdL:(
<PaulFertser> Guest92: so the driver is fine now.
<PaulFertser> Guest92: extra taps seem like TDI is not connected.
<PaulFertser> Guest92: or not outputting data.
<PaulFertser> Guest92: are you sure that's with vtref connected?
<Guest92> vtref is connected to what is stated as VCC
<Guest92> there is a "VDD flash" point PaulFertser
<PaulFertser> Guest92: did you measure that it's at a stable 3.3 V?
<PaulFertser> Guest92: I still suspect some TDI issue.
Guest2711 has quit [Quit: Client closed]
<PaulFertser> Guest92: probably just rearranging it on your desk will change the results...
<PaulFertser> It would be nice to see with an oscilloscope signals as they arrive on the target board.
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #openocd
<Guest92> sorrry about the long delay PaulFertser, so i dare not restart to confirm the issue but im currently getting this  https://pastebin.com/w5vNK0Uf
<Guest92> PaulFertser im going to try "openocd -f /interface/altera-usb-blaster.cfg -f target/at91sam7sx.cfg -c "program AT91SAM7s256.bin 0x00100000 verify reset exit" "   does this seem correct
<Guest92> PaulFertser :D  https://pastebin.com/0NuCi7UH
<karlp> whee
Guest92 has quit [Quit: Client closed]
Guest92 has joined #openocd
Boban has quit [Quit: Client closed]
<Guest92> i got disconnected so not sure if i missed any reply.   PaulFertser i have just tested the carprog and the result is....perfect :D   thanks again for your continued support, i know it must have been frustrating being so patient with me but without that help i would be no where so again and again i thank you:)
* karlp is glad it worked out :)
<Guest92> :D  thank you also karlp
<Guest92> the issue was pin 55 floating but im not sure why that was, as you noted earlier when looking at the datasheet it should be fine and that is what the guide states to do but in my case   55 floating = bad.  55 low = bad.  55 high = bad.  power up device with 55 floating and then short to 3.3v for a second while powered and BAM it works
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #openocd