gbulmer
Moderator
I was looking at some STM32F documents, including "Application note AN2586; STM32F10xxx hardware development: getting started".
In "Figure 12. JTAG connector implementation", on page 19/28, it shows nJTRST and nRSTIN as two distinct signals.
Also, the 20-pin layout in "The Definitive Guide to the ARM Cortex-M3" by Joseph Yiu seems to show two distinct signals.
Maples 8-pin JTAG header has them wired together.
Is that a mistake on Maple?
Well, the circuit and connector works for me using Olimex ARM-USB-OCD JTAG adapter. I can program the Maple's flash memory, reset the board, halt the board, and debug using breakpoints. So I would say that it is not a mistake.
Note that the OpenOCD config file has the following line:
reset_config trst_and_srst
This mode defaults to combined so this line is really
reset_config trst_and_srst combined
The OpenOCD STM32 docs say that this is a valid JTAG mode. Since it works, I think the docs are right. :-)
gbulmer
Moderator
Adam - thank you for the details.
I have assumed the Maple board works using "Olimex ARM-USB-OCD JTAG adapter" because that is the JTAG adapter recommended by LeafLabs.
The detail that you have provided is helpful. I think we can assume from the "reset_config trst_and_srst combined" configuration statement that the two signals are not always wired together on the motherboard, or their would be no need for that configuration option. Agree?
In another thread http://forums.leaflabs.com/topic.php?id=536&page=2, you tried the Olimex ARM-USB-TINY and it didn't work. Have you got that JTAG adapter working now?
If it is fixed by adding the "reset_config trst_and_srst combined" configuration option, I would feel better.
But that isn't the point. Something working never proves the absence of an error, it proves that specific case, not all the others.
Maple should work with all STM32F JTAG adapters that support 10-pin JTAG. Agree?
Their is a preponderance of documentation from ST Micro, and ARM that suggest the two signals are separate.
The OpenOCD STM32 docs say that this is a valid JTAG mode. Since it works, I think the docs are right. :-)
Which docs are you referring to, OpenOCD, ST Micro's STM32F, ARM Cortex-M3, ARM JTAG?
Which other JTAG adapters work?
Which other JTAG adapters fail?
gbulmer,
Re: Olimex ARM-USB-TINY, I am sad to report that it doesn't work. I don't know why. It should work according to the Olimex docs, as they think the only differences are "no output buffers just current limitation resistor protectors, no RS232, no power supply to target" which shouldn't matter. But it does.
Re: there are other combinations of trst and srst, yes, I think there probably are... but I am not an embedded ARM expert and don't know much about this. On the Maple R5 schematic, the system reset NRST and the JTAG tap reset TRST are indeed wired together. The OpenOCD docs imply that there are other ways to do it:
In the best case, OpenOCD can hold SRST, then reset the TAPs via TRST and send commands through JTAG to halt the CPU at the reset vector before the 1st instruction is executed. Then when it finally releases the SRST signal, the system is halted under debugger control before any code has executed. This is the behavior required to support the reset halt and reset init commands; after reset init a board-specific script might do things like setting up DRAM.
http://openocd.berlios.de/doc/html/Reset-Configuration.html#Reset-Configuration
And I am not able to get the reset halt command to work - I can reset, and I can halt, but not both together. When I do, I get the following response:
Open On-Chip Debugger
> reset halt
JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Halt timed out, wake up GDB.
timed out while waiting for target halted
TARGET: stm32.cpu - Not halted
Command handler execution failed
in procedure 'reset' called at file "command.c", line 650
called at file "command.c", line 361I am guessing that means that if I wanted to debug system startup code, I would have a hard time. But that's a guess!
Re: not proving the absence of an error, yes, you are right. The circuit could still work and contain an error.
Re: fixing using various combinations of the reset_config line - I tried several and couldn't find one that worked.
Re: what STM32 JTAG circuit diagram was I referring to, it's figure 12 on page 19 of this document:
Here's a PNG:
Our current schematic matches this one, except that in the diagram above, the STM32's nRSTIN is connected separately to the JTAG connector's nSRST, and the STM32's nJTRST is connected to the JTAG connector's nTRST. They are not combined, they are separate.
Ideally the next rev of Maple would conform to this diagram, though, since it is what ST recommends. Does this allow a reset halt? I don't know, but I think it would. Does it matter...? It would probably be more compatible with other JTAG adapters... but again, I don't know for sure.
Re: Maple should support all STM32F JTAG adapters that support 10 pin JTAG, yes, I agree. And it
does bug me that the ARM-USB-TINY doesn't work. But - now that I have a working JTAG adapter this is less of a priority for me. I want to make sure the adapter PCB we designed works. But after that - I want to go on to debugging my project. :-)
gbulmer
Moderator
Adam - so Maple connecting together nJTRST and nTRST may be an error.
Connecting together nJTRST and nTRST may prevent some JTAG adapters from working, with Olimex ARM-USB-TINY being a concrete example.
Okie - do you agree, and if so, will you fix in a future revision?
Also - the 10 pin connector will make things much easier to build - it's super-hard to find in-stock ribbon cable and polarized connectors for the 8-pin connector, but very easy for the 10-pin.
For instance, I can't even find 8-conductor ribbon cable, I had to take 10-conductor and strip off 2 conductors. But 10-conductor is standard. Same for the connectors - lots of 10-pin male polarized 4-wall shrouded headers, and lots of 10-pin female ribbon cable connectors, but few 8 pin ones.
And argh, no 8-pin 4-wall vertical shrouded headers in stock anywhere I can find!
gbulmer
Moderator
Real 8-pin IDC headers and connectors are awful to get here. IDC takes huge PCB area for small numbers of pins. I'm not surprised ARM now define 0.05" pitch sockets for JTAG.
I looked in the summer and found very few 2x4 shrouded or boxed headers in the UK.
10-pin easy.
I think the things I found were not 'proper' IDC in the usual width, but some different connector, some had shrouds which were open at the ends, but weren't HE13/HE14.
Real 8-pin boxed/shrouded headers appeared on datasheets, but no one stocked them. Our theory was 8-way IDC sockets are so big that they take almost as much width as an 8x1, and more PCB area than 7x3 pin headers, so no point using them.
We had a problem with 8 way ribbon cable. Like you we split 10-way ribbon cable.
I finally gave up on 8-pin as too awkward and expensive.
BUT, it isn't essential anyway, is it?
I thought the JTAG adapter could just plug directly onto the board, couldn't it?
I add J-Link debugger on back side of my maple board (also with usb hub chip). It's need 20x25 mm square but very comfortable for debug. Now need last step - integrate debugger support to Visual Studio (such as http://www.wingdb.com/) and i've full flavor.
gbulmber,
Re: plugging directly into the back of the board, that is a good idea, it didn't occur to me. How would we accomplish it?
One of my requirements is to not have exposed pins on the back of the Maple, which is why I used a right-angle shrouded header. You are right, it takes up a lot of space.
I think if we used a vertical shrouded header that would work.
How do we prevent the two boards from shorting each other out? There are a lot of exposed solder points on the bottoms of both Maple and the Maple JTAG adapter.
Also - this forum does not allow us to Private Message each other (PM) - I am adamf at pobox dot com if you want to email me directly. Will you tell me your email address? I would like to send you an adapter board if it works. Yes I know you are in the UK. :-)
gbulmer, Adam,
Everything you'd done and said is great.
I agree, nJTRST and nTRST should be disconnected. I would like to make that change on the next revision. We are freezing the hardware, in a big way, on Maple and future revisions of Maple, but, in my opinion, this is a good change that should be made. Personally, I also think that switching to the standard ARM 10-pin JTAG connector populating that component would be desirable. The main priority is giving folks the go-ahead on shields and other hardware development for Maple so that they can be confident that nothing will change that will affect them.
While we're on it, I'll mention some other things that are on my mind that may or may not ought to be changed:
1. Some type of jumpers on VBAT and BOOT1, keeping them connected as they are by default but making them easier to connect to something else if needed.
2. Adding an empty pin header hole connected to BOOT0, or maybe some type of empty/disconnected jumper (maybe a solder jumper?)
Two other things that I would really love to do, but may be too much to change for the hardware freeze:
1. Turning the LiPo connector 180deg to work better with enclosures.
2. Adding diodes for automatic power selection, possibly eliminating the PWRSEL header, or maybe some of its pins
3. Component holes next to the LiPo charger's indicator LEDs for thruhole enclosure mounting.
What are your thoughts? Can you think of anything else? Some of these things haven't been talked about much, if at all. With maybe the exception of the power selection stuff, in my mind, it seems like they could be non-interfering with any development with a high probability. What are your thoughts?
> 2. Adding diodes for automatic power selection, possibly eliminating the PWRSEL header, or maybe some of its pins
I would /love/ this feature, especially if the PWRSEL header gets eliminated completely. Especially especially if the battery charges automatically too, but that might be too much to ask? Power supply design is not my strongest skill...
gbulmer
Moderator
Adam -
One of my requirements is to not have exposed pins on the back of the Maple, which is why I used a right-angle shrouded header. ...I think if we used a vertical shrouded header that would work.
There are three appoaches I can think of which might work:
1. put the JTAG adapter on top of the Maple, this avoids exposed pins on the bottom :-)
2. as you say, put a shrouded vertical header on the bottom, and have the adapter at right angles to the Maple. That will connect if the adapter has a 2x4 right angle plug, with it raised above the PCB (with a bit of 'packing' while soldering it), so that the adapter PCB doesn't get in the way.
3. use a right angle 2x10 IDC so the adapter and Maple are parallel.
I've emailed.
gbulmer
Moderator
okie - I'm not sure I can give good advice.
I'd try to freeze the hardware for at least 6 months at a time. I worked with car companies on product definition, design and development for years, and they had some very persuasive statistics about the cost of change.
I think I've said I focus on low-cost robotics for schools.
My view is schools do not use LiPo's; too delicate and dangerous, so I don't care.
I would make the JTAG header compatible with a standard connector at some point because it doesn't make any sense for it to be different from an ARM recommended connector.
All your other ideas seem like good things to do, but I don't have any view on how many extra sales they'd cause in the next 6-12 months.
okie,
Re: separating nJTRST and nTRST, thank you!
Re: Boot0/Boot1, is this so users could select other boot modes (ram, flash, etc.)? Could be nice, but most of my programs are too big for RAM anyway.
For VBAT, is that to enable a "sleep" mode...? For RTC and backup registers?
Re: automatic power detection - that would be nice, especially if it could automatically charge the LiPo battery, but I don't need this right away. I can wait 6 months - since it will take me that long to build a shield and a prototype of my Maple-based wifi-single-board device.
Re: component holes for attaching cable-mounted LEDs for enclosure panels, that would be nice, but not necessary. I can run LEDs from other ports if necessary. I mainly plan to use an LCD for indicators.
My number one wish for the next rev is... give an option for the high-density STM32. I really want that extra RAM. Since the med-density and hi-density STM32s are pin-compatible... would you be willing to consider it?
If not, no problem... I can either replace the STM32 chip myself, or have a Maple board done at a proto house. But it would be more convenient to just get a few from you guys!
You must log in to post.
