1. As it comes to datasheets they are indeed divided. "Reference manual" is complex descriptions of how to do things, configuration and detailed considerations about the whole MCU. "Datasheet" is on the other hand only a brief description of MCU features, pinouts, packages etc. There is also very helpful document for every STM32 line (F1,2...7) "Getting started with STM32F7xxxx MCU hardware development" which provides you with many informations if case you would like to design a custom board. In comparison to AVRs, registers descriptions are sometimes put a bit aside from main description of particular chapter.

2. STM32CubeMX is not a library, just a useful program from ST, which enables you to set pinouts, its configurations, set systems clocks etc and then, at the end, generate a code and the whole project. The project can be generated specially for Eclipse (System Workbench for STM32) in which you just import this project and you're ready to go. The new library is HAL ("hardware abstraction layer") and try to use it. That's the new thing and sometimes it's hard to find examples on the Internet but don't teach your students outdated technologies. HAL is convenient to use and has documentation, so I think it's better choice.

3. Which library? Anyway it shouldn't be a problem to google them, I think.

4. Even if you would like to use only one OS (like Windows), Eclipse (AC6 = System workbench for STM32) is - I think - the best option. There is for example Keil's uVision 5 - but that's really terrible IDE - it lacks most of features IDE should offer (refractoring, click-and-search, proper error checking, finding references and many, many more). So, all in all, the Eclipse is pretty much the only reasonable choice for IDE for STM32.

You've got a few questions there, I'll try to address them in order. First, for JTAG:

Conceptually, yes, that's correct -- JTAG is a chain / a shift-register and you've connected it as such. At a system-level, here are the thoughts I have:

• Will I ever end up with a "broken" chain? I.E., are both devices in the same power-domain (on at the same time), and are both devices capable of JTAG operation regardless of state -- i.e., if software is not loaded, or is otherwise corrupt, is the JTAG TAP of the part unaffected?

• Physically, how close are these devices located to each other? The simplest thing to do for TCK is to feed it to a clock buffer, and drive it point-to-point to each device. Otherwise, you can do simple transmission line design and route in a "fly-by" style, and terminate the line with AC termination (resistor and capacitor in series to GND). Even at slow JTAG speeds, a modern JTAG debugger may drive fast edges and the trace may end up long enough to warrant considering TL effects.

• Is my JTAG software (urjtag, etc.) capable of handling a chain of dissimilar devices? Many JTAG solutions are very brittle, and break when unknown devices are in the chain. At a minimum, you should have the BSDL files of each device available so software recognizes them (via IDCODE), and knows how long the IR of each part is, at minimum. The JTAG DRs will then be defined on a per-part basis.

The most common issue I see folks run into are "broken" chains, where TDO doesn't make it out because one of the parts isn't there (removable add-in cards), is off, or otherwise in a state where JTAG is in-operable. Adding a bypass resistor that can be loaded to short TDI/TDO across a part may be a good idea.

Other issues include poor signal integrity on TCK -- I was on a project where the designer had TCK fanning out to I think 10+ nodes across many circuit boards, with no re-driving whatsoever. As you may imagine, the chain was basically unusable due to all the reflections and horrid signal integrity.

Secondary questions:

Is there any "standard" pinout I should follow when designing the JTAG connector?

No, but as you stated, there are pseudo-standards from the vendors, like Altera's for their USBBlaster/ByteBlaster/etc, or the "standard" ARM pinout for a J-Link or similar. What you need to consider is:

• do you want to solder together custom harnesses for the debuggers? If so, how many do you have to build for your program / project? Hand-building 20 harnesses would suck, and a SW engineer is going to be really upset with you if he wastes 10 hours chasing a problem that turns out to be an intermittent crimp on TDO.

• do you want to put an additional connector on the board just for JTAG, or utilize a connector-less solution like Tag-Connect that is more suited for end-of-line testing with a $0 BOM Cost?

In either case, you have to provide at minimum: VCC (for sense), GND, TCK, TMS, TDI, TDO and TRST# for a minimal JTAG implementation. ESD protection isn't a bad idea here either.

How to debug both chips at once, if it is even possible?

This is all on the host SW end -- you can do this, as long as your SW (urjtag, OpenOCD) can juggle the state of both parts, but it's tricky. I don't know what your application is, but my gut says you're going to spend most of your JTAG time for the CPLD programming it and maybe hooking into a ChipScope / SignalTap ILA instance. For the MCU, I can see more detailed debug going on for SW with a Segger J-Link or similar -- in this case, the debug software just needs to be intelligent enough to support a JTAG chain where it will over/undershift appropriately to handle the extra device in the chain. Ideally, the CPLD sits in BYPASS and simply adds an extra padding bit/clock cycle to the JTAG master.

Is it a good idea to share clocks between the two chips?

Sure, it saves you another oscillator, assuming electrically it works (VIH/VIL/etc.) and precision requirements are met. Are you OK with the CPLD being "dead" if the MCU doesn't come up first? It enforces a dependence in the system in terms of power-up order. I might add a RESET line driven by the MCU to the CPLD as well, so your MCU can hold CPLD logic in RESET, start the clock, and then de-assert RESET. I don't recall if that family of Altera part has an internal RC oscillator used for initial configuration.

As for EMI/EMC, that's out of scope here for this question (IMO), but follow best practices for a single-ended clock signal. Don't make it any longer than you need too, use series termination if needed, and use spread-spectrum if needed / tolerable.

What is a good bus interconnect for the two chips?

I don't know what your application is. SPI is simple and requires very few wires. Parallel would certainly work, but again, I don't know the data-rate or latency requirements, but of course it is more traces.