Replies: 21 comments 46 replies
-
|
It's really hard to debug hardware without it in front of me, my first thought is one of the pins is connected to the wrong GPIO, or there is a loose connection that is connecting when you push a probe on it.
This suggests suggests no data is being read. Which could mean a pin is grounded or disconnected. You've probably read all the discussions, but double check this comment about pin numbering on the RPi.
This doesn't look right, I think it should be 1500 kHz. What do you have in You can run openocd -d |
Beta Was this translation helpful? Give feedback.
-
|
I found that GND is not properly connected to board ground, could be this. The am1802.cfg is straight from the hacktribe repo, but I had edited it temporarily for 10khz to be sure. It is definitely not the wrong GPIO pins and I am very aware of logical vs physical pin numbering. Maybe you remember this or have it noted down: TDO should read 0v against board ground because it is logic low? And does TRS pin read 2.2V steadily? Once the JLink clones come in the mail I will try with those as well. |
Beta Was this translation helpful? Give feedback.
-
Definitely need a good ground connection. The ground plane will drain heat from the iron quickly, I had to increase the temperature quite a lot to get a good solder joint.
I'm not sure, but it makes sense.
I can't test this, but the RPi GPIO tolerate 3.3 V. I think we need TRST connected to initialise the CPU JTAG controller, it probably won't work without it. Can you post the debug log from |
Beta Was this translation helpful? Give feedback.
-
|
Hey so I fixed GND joint but still no luck, however, TMS, TCK and TRS seem to consistently measure 1.5k ohm against GND&board ground, but no solder bridges between any of these whatsoever. Did I toast my board, or is this behavior normal?
|
Beta Was this translation helpful? Give feedback.
-
I think this is normal, but I can't open up an electribe to check right now.
What happens when you boot without the RPi connected? Is it any different to before you soldered the header? Did you test with the TRS line connected this time?
I'm not sure I can offer you anything more helpful than the logs, If you post some photos of your setup I'll try to look for issues, but I doubt I can find anything from a photo you can't see with a meter. |
Beta Was this translation helpful? Give feedback.
-
|
Electribe 2 works completely fine. I tested with TRS line yes. I'll wait for some Chinese J-Link clones in the mail and see if those work, who knows!
|
Beta Was this translation helpful? Give feedback.
-
What is the resistance between TDO and GND? If it's 0 you have a short and it will never pull high. It's hard to tell from the photo, but it might be worth reflowing the header solder joints to ensure a good connection. |
Beta Was this translation helpful? Give feedback.
-
|
Infinite, I will reflow the joint since maybe the resistance should read a steady 1.5k just like other pins. I suspect, maybe my multimeter touched the solder, but not the header, and hence beeped deceptively |
Beta Was this translation helpful? Give feedback.
-
|
Some of these pads are inline with the header pins, you'll have to trace to work out which ones. If you check continuity between those pads and the RPi, you know the full connection is good. 
|
Beta Was this translation helpful? Give feedback.
-
|
Great tip! I compared to the BF523 holes and TDO corresponds to the 6th pad there. In my AM1802 header it doesn't, even after melting it properly again. I'm pretty certain I found the problem: I remember burning/oxidising the copper TDO pad a bit in last attempt to solder the header, it had black-ish marks, but not severe . Unfortunately I don't have a photo of this : ( Maybe I can tape off all irrelevant pads and dirtily install a jumper wire between the TDO pin and that pad instead? |
Beta Was this translation helpful? Give feedback.
-
It won't necessarily be the same number pad, I think there are more pads for the Blackfin, but it should definitely be connected to one of them. You should be able to see the PCB trace
The PCB holes are plated through, but I think they only connect to the trace on one side of the board. If the hole plating is disconnected from the PCB trace, you may be able to solder a small wire from the pad to the header pin.
Removing the header might be easier if you can pull the plastic casing off and remove each pin one at a time. |
Beta Was this translation helpful? Give feedback.
-
|
Judging by this photo, CPU TDO is the third pad from the end closest to the CPU. 
|
Beta Was this translation helpful? Give feedback.
-
|
Alright gonna try that thanks ! |
Beta Was this translation helpful? Give feedback.
-
|
Well, did I fry my board? 🥴 No continuity whatsoever between TDO and those pads |
Beta Was this translation helpful? Give feedback.
-
|
Definitely looks like you burnt the plating away from the PCB trace. You could still attach a debugger by soldering a ZIF connector to those pads, but it's a harder job than soldering the header. It would be worth spending some time practicing drag soldering and hot air rework, I think you can get practice boards with footprints for different pin pitches. You should be able to find a pre-soldered breakout board for the RPi end, so you only need to solder the E2 connector. You would want to clean off the existing solder before starting, it will have quite a high melting point. If you live anywhere near a hackspace, they usually have decent soldering tools. |
Beta Was this translation helpful? Give feedback.
-
|
Alright thanks anyway. Learnt a lot from this ordeal and it was fun and educationally valuable. I'm confident that I can solder my other electribe with no problems, and in the meantime i can learn the things you suggested :) |
Beta Was this translation helpful? Give feedback.
-
|
After bricking 2 electribes I managed to do it nicely, and cleanly now. I can dump memory and control the CPU using JLink Commander so that's good. But I do wonder about this: This time, on a new electribe, again TRST is a steady 2.2V against ground. If not for that, I would be able to load binaries into CPU using JLinkExe |
Beta Was this translation helpful? Give feedback.
-
|
TRST only resets the JTAG test logic, not the whole processor, have a look at sections 3.7.1, 6.4, and 6.24.1 in the AM1802 datasheet. There is an active low RESET pin, but I haven't found it on the board and it would only reset the CPU, not the whole device. I was manually power cycling the whole device using the soldered switch every time to load new firmware. If you have a JLink you can use the JlinkGDBServer command line. EDIT: These were in the wrong order:
The ZIF footprints inline with the JTAG headers have some extra pins, I think they are clocks and EMU signals for unified debugging of both processors, but I haven't really investigated them. We could probably hook up the TRST output of the debugger to cycle the power. Also, SW1 could be a good candidate for a reset switch: 
|
Beta Was this translation helpful? Give feedback.
-
|
Alright |
Beta Was this translation helpful? Give feedback.
-
|
EDIT: If you have JLink connected and powered, the electribe should wait in ARM ROM when it is powered up.
You set a timeout of 0 ms, change this to |
Beta Was this translation helpful? Give feedback.
-
This should be fine.
|
Beta Was this translation helpful? Give feedback.
-
|
The docs say the command line version has a default timeout of 0 ms, so you need to explicitly set |
Beta Was this translation helpful? Give feedback.
-
|
Well I've tried -notimeout, and -timeout 5000. For the record, here's the output of that It doesn't wait 5 seconds, so that's weird. "GDB Server automatically closes after a timeout of 5 seconds when no target voltage can |
Beta Was this translation helpful? Give feedback.
-
I can't check, all my stuff's packed away. I install JLink software from the AUR,, I think the JLink will prompt to update if it is out of date.
Is it any different if you leave it plugged in and use the switch instead? The only other thing I can think of is maybe some connection is noisy and only working intermittently. |
Beta Was this translation helpful? Give feedback.
-
|
Possible workaround if you can still get it to connect the way you did in this comment. In // Disable and clear interrupts in AINTC.
IntAINTCInit();
// Disable cache and MMU.
CP15ICacheFlush();
CP15DCacheFlush();
CP15ICacheDisable();
CP15DCacheDisable();
CP15MMUDisable();
// Set interrupt vector to ARM RAM.
CP15HighVectorEnable();It's jank, but it's what I'm doing in the Hacktribe sysex loader. You should also clear the On Chip RAM to zeroes in the GDB init script, before loading the binary. EDIT: In the Hacktribe sysex loader I also have this in @ Reset hardware.
bl dev_board_terminate
@ Disable interrupts.
mrs r0,CPSR
orr r0,#0xc0
msr CPSR,r0The |
Beta Was this translation helpful? Give feedback.
-
It's triggering interrupts, I missed a bit last night, see my edit above.
I was thinking this is the only difference I can see between what you are doing and what I was doing, so it is worth ruling out. Maybe some part of the board is powered before using the power switch and this is causing the issue, although it's unlikely.
Yes, the backlight is switched on in factory SBL.
You will be able to see your code more clearly in the disassembly if there is nothing left over.
Trying to debug hardware remotely I can only really make guesses, but I reckon there is some noise on the connection between the JLink and the board. This could be interpreted as a response and end the timeout before it starts. It could be due to a poor joint or the wires being too long. I've also had debug adapters be temperamental when connected via USB hubs or long leads, but that probably wouldn't cause the issue you have. |
Beta Was this translation helpful? Give feedback.
-
Mains power vs toggle switch power is the same. Although a bit of nuance: I must say that I didn't have an unpopulated pin header in my motherboard so I had to bridge the two dots of solder to accomplish the same thing.
|
Beta Was this translation helpful? Give feedback.
-
Do you have TRST connected between the board and JLink? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, but that doesn't seem to make a difference now that I disconnected it. I tried the other probe, without updated firmware. Still same gdb server thing where it quits and doesn't wait |
Beta Was this translation helpful? Give feedback.
-
void per_uart_terminate(uint8_t instance) {
static uint32_t address[] = {SOC_UART_0_REGS, SOC_UART_1_REGS};
// Empty FIFO.
while ((UART_THR_TSR_EMPTY | UART_THR_EMPTY) !=
(HWREG(address[instance] + UART_LSR) &
(UART_THR_TSR_EMPTY | UART_THR_EMPTY)))
;
UARTIntDisable(address[instance], 0xffffffff);
// Disable UART.
UARTDisable(address[instance]);
} |
Beta Was this translation helpful? Give feedback.
-
|
I think at this point you need a scope, or at least a logic analyser, to check what is actually happening between the board and debugger. The workaround I suggested will never be a good solution and I would concentrate on working out why JLinkGDBServer doesn't wait. I reckon it probably is waiting, but is receiving something it thinks is a response and trying to process invalid data. |
Beta Was this translation helpful? Give feedback.
-
|
Quite a headscratcher with big potential to land me into forensic psychiatry, but on the positive side, it is a great learning experience You're right, I'll probably go and study about that before I ask any more of you |
Beta Was this translation helpful? Give feedback.
-
|
I figured out the problem; My Chinese JLink clones have an optional internal jump for VTref. I removed it and GDB waits checking for target voltage. Only issue now is, where do you tap the KORG reference voltage from ? |
Beta Was this translation helpful? Give feedback.
-
|
I don't know, but I've just noticed in the Freetribe Docs I wrote this:
So maybe I was wrong about the order in my comment above. What happens if you power up the electribe before running JLinkGDBServer? |
Beta Was this translation helpful? Give feedback.
-
|
Do you have the real JLink? I don't assume there's a difference between our electribes. I'm gonna solder a wire to one of the J10 holes now to power VTRef of my Chinese JLink v9-G clone. I'm pretty confident this is gonna work |
Beta Was this translation helpful? Give feedback.
-
|
I've edited my comments above to reflect what I wrote in the docs. I think the issue is powering things up in the wrong order. Based on what I wrote in the docs 2 years ago, I think you should try:
But I thought this was what you tried originally, and it booted into SBL, which it shouldn't. Maybe there is PCB revision that prevents it entering emulation mode if a debugger is connected. |
Beta Was this translation helpful? Give feedback.
-
|
I didn't realize it should boot into ARM and then halt in the first place, a-ha!
|
Beta Was this translation helpful? Give feedback.
-
|
What prompts it to wait in ARM ROM anyway? some response from the JLink? It's a horrible idea, but what if I write a |
Beta Was this translation helpful? Give feedback.
-
|
Alright the VTRef from the E2 works 👍🏻 But JLinkGDBServer ends up polling for connection so still SBL runs 🙄 |
Beta Was this translation helpful? Give feedback.
-
I think the debug adapter releases TRST (high) after power on reset, then it enters emulation boot mode instead of whatever is set by the boot mode pins. Then instead of executing the AIS from flash, the ROM Bootloader (RBL) just waits in a loop for the debugger to load some code. See section 6.4.1 of the datasheet.
Can't write the ROM, it's read-only. |
Beta Was this translation helpful? Give feedback.
-
It's supposed to connect again, but the CPU should now be looping in the RBL.
I don't understand what you're timing, there shouldn't be anything that needs correct timing. If you leave If you're getting different results each time with the same software process, then you have a hardware issue, almost certainly a short or poor connection, most likely on the TRST line. |
Beta Was this translation helpful? Give feedback.
-
|
When cutting power, the device stays on for a little bit with screen off and if i bring it back up soon enough, i get it to halt there. I wanted to avoid it, but I will figure out what happens with TRST Using logic analyzer |
Beta Was this translation helpful? Give feedback.
-
This could be your issue. It sounds like capacitors in the power supply are keeping the CPU powered. If you use the soldered switch, or unplug the barrel jack, it will cut the power after the capacitors and you should get more consistent results. |
Beta Was this translation helpful? Give feedback.
-
|
With OpenOCD are you using JLINK or RPi? I haven't tried JLINK and OpenOCD, so the process may work differently than documented. |
Beta Was this translation helpful? Give feedback.
-
|
Nono, not OpenOCD as backend for JLink. Openocd rpi GPIO versus JLink Chinese clone "hlink" . Ill rule out TRST connection issues first and then report back. |
Beta Was this translation helpful? Give feedback.
-
What do you think of IC1 middle pin->pink->teal(C10, which on the other side is next to "J9" the jtag header) being a reset pin? I'll try OpenOCD now (from the instructions on wiki) and post the logs etc |
Beta Was this translation helpful? Give feedback.
-
|
I don't want to guess the circuit without it on a test bench in front of me. I would trace the connections from the other pins of that IC, then use a scope to see what happens during power up and shutdown. |
Beta Was this translation helpful? Give feedback.
-
|
Hi bang, have you still got a backup somewhere where you correctly initialize SPI for the Flash read/write functionality? Since I just want to get on with development, my idea is to write a Was this when Flash still worked? |
Beta Was this translation helpful? Give feedback.
-
In the flash the bootloader is an Application Image Script (AIS) executed by the ROM Bootloader (RBL), not ARM ASM executed directly by the CPU. I'm not sure what will happen if the RBL finds bytes it doesn't understand, it definitely won't branch to the On-Chip RAM. This is the commit before I updated the SPI initialisation. To get flash working, comment out both calls to It's a long time since I've run that code, I don't know what bugs there are and I can't guarantee it won't soft brick your flash. It's worth getting an SOIC clip to program the flash directly using JLink or FlashROM, Pomona 5250 is a good one. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks. It's been a while and I had used your commit to dump flash. I had made an ImHex script to decode AIS from SBL. It's funny that the RBL AIS contains commands that are not documented by Texas Instruments, and I wonder what those are. Luckily the SBL does contain only documented commands: First section load copies the vector table, second and third, I don't know. Maybe you have an idea? For future reference the AIS decoder: |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
So I soldered a toggle switch so power can be always held, and a JTAG header, connected it to RPi 4B. Checked all pins and no bridges, proper 3.3V against board ground except on TRST pin which is steady 2.2V, not sure if that's correct but I disconnected it from RPi GPIO anyway.
Yet, if I boot my E2, no matter what I do I get this output:
I am certain the electrical connections are double checked, even tested Pi GPIO and it's toggleable. Still 0x00.
openocd.cfg:
What am I doing wrong here?
Beta Was this translation helpful? Give feedback.
All reactions