probably a problem with 3.3V circuit operation and battery: PMOS gate only gets pulled up to 3.3V, but likely needs the full battery voltage. Replacing PMOS with SOT-323 footprint might help routing.

There are no 22uF or larger 0603 ceramic caps

Should we stack boards to the bottom instead?

Hi all, me again :-)

Here is another thing I don't understand in the latest board revision: the USB ground and VSS seem to be disconnected from each other? So VSS is floating? Maybe I am missing something really basic?

Normally they should be connected (of course, through a ferrite bead such as BLM15HG601SN1D or something like this, to avoid connection/disconnection spikes from damaging the MCU)

To quote the readme file from summon-arm-toolchain:

THIS PROJECT IS NOT UNDER ACTIVE DEVELOPMENT ANY MORE.
THERE IS A BETTER REPLACEMENT FOR THIS!
Since not so long ago there is a very good toolchain available that replaces
summon-arm-toolchain. Is better tested and there are more people working on it.
Consider visiting:
https://launchpad.net/gcc-arm-embedded

I have been using the linaro toolchain in order to compile programs for STM32F0,3,4 as well as LPC11xx and it works flawlessly. Also it is much easier to install. Just extract the files to /opt/ and edit your .bashrc (.zshrc) to add the bin directory to your path.

the sot23-5 footprint basically has no enlarged pads at all, making it hard for hand soldering

can't easily bridge the pads of the solder jumper because the pads are too far apart

Not sure if it's available already, but it would be really cool to just drag and drop your firmware on, like: http://emerythacks.blogspot.com/2012/12/usb-mass-storage-bootloader-for.html

The CN3083 pulls the output low only at about 4.4V for a full battery. This would lead to the FET shorting 4.4V into the battery.

We need to come up with other ways of switching the battery.

the cheaper buttons have a slightly smaller footprint; adapt for that.

We currently have a really long GND current loop for the MCU and its decoupling caps (C8 and C2).

with a clean mingw, msys, arm-none-eabi, ruby install.
neatly compiles all the sources but runs into issues at linking.

seem to be related to the real-ld ruby shell script and -flto

even though most users are on linux, it seems a working windows environment is very close - and going the last mile would not be a bad thing.

People will generally be using the basic interfaces like the UART, SPI etc. a lot. Makes sense to standardize what pins these use for ease of use.

The ideal scenario, I think, would be:

• Default pins for UART, SPI, I2C, all 8 FTM0 channels brought out
• No conflicts between any of them, i.e. all usable at the same time
• Only use the 14-pin headers on either side for these, to make them easy to break out to a breadboard or whatever

I looked at the options a bit and here's what I've determined so far:

• SPI: PU5 = SIN, PU6 = SOUT, PU7 = SCK. Would be nice to change CS for the flash to CS0 since it doesn't conflict with FTM.
• UART0: PU1 = TX, PU2 = RX, conflicts with FTM, or PL4 = RX, PR5 = TX
• UART1: PU12 = TX, PU13 = RX, conflicts with FTM
• UART2: PU5 = TX, PU6 = RX, conflicts with SPI
• I2C: PL10 = SCL, PL11 = SDA
• PU14-12, PU4-1 can all be used as FTM channels. Channel 0 of the FTM is currently only brought out on the debug and other right-side connector.

I think the ideal scenario could be accomplished if some of the pins were moved around, namely:

• Change flash footprint CS pin from SPI0_PCS1 (PTD4) to SPI0_PCS0 (PTD0) so it doesn't conflict with FTM0_CH4
• Swap PR3 (PTC1) with the same SPI0_PCS0/PTD0 pin -- since it's reserved anyway -- so that all the FTM signals are available on the upper connector.
• Swap PR5 (PTB17) with one of the pins on the lower header, preferrably PL5 (PTA4) so we can access UART0 RX/TX with no conflicts.

What do you guys think? I have no idea how much space there is for routing this, but I think it would remove having to think about conflicting pin muxes so much, so it might be worth it.

Hi all!

Maybe I am not understanding something basic, but I am looking at the N-000056 and I don't get what it is supposed to be used. This is technically the Micro USB OTG ID which needs to be connected to signal ground if the board needs to act as a host, and left unconnected when acting as a slave.

However, it is connected to the pad "USB_D-" on the back. In the schematics it is connected to an independent P6 which isn't connected to anything.

Shouldn't we enabling connecting this to GNDPWR in order to selectively enable USB OTG host mode?

Brian pointed out that the analog lines tend to pick up noise from USB. We should check how bad it is, and check whether we need to think about addressing this issue.

Better to have ports on the edge

Consider organize IO pins in ports groups with power pins like JeeNode
http://jeelabs.net/projects/hardware/wiki/JeeNode

That would allow to connect peripherals easily and use already designed plugs http://jeelabs.com/collections/all/plugs

board should have mounting holes (M3?)

Need pin names on silkscreen and in general proper silkscreen for parts.

Probably need to generate new footprints for all of the parts.

The NUC120 defaults its PLL to 12MHz -> 48MHz. By using a 8MHz resonator we're just making initialization code unnecessarily complicated.

single library is getting too big - link only parts. also needed to avoid automatic linking of strong interrupt vector symbols

For LiPo connection pads for Jst connector would be usefull.

I followed all the steps on the wiki to get the mchck code compiling. I am using xubuntu. I also installed Ruby 1.8

When i do 'make' in the examples/blink I get these errors.

arm-none-eabi-gcc -E -o blink.ld-template -P -CC -I../../toolchain//ld -I. -DTARGET_LDSCRIPT='"MK20DX32VLF5.ld"' -DMEMCFG_LDSCRIPT='"app.ld"' ../../toolchain//ld/link.ld.S
arm-none-eabi-gcc -o blink.elf -fplan9-extensions -ggdb3 -Os -Wall -Wno-main -mcpu=cortex-m4 -msoft-float -mthumb -ffunction-sections -fdata-sections -fno-builtin -fstrict-volatile-bitfields -flto -fno-use-linker-plugin -Wl,--gc-sections -fwhole-program -T blink.ld-template -nostartfiles -Wl,-Map=blink.map -Wl,-output-linker-script=blink.ld blink.o
../../toolchain//scripts/real-ld:77: syntax error, unexpected ',', expecting ']'
...-T", linker_in, *object_files, *call_args, "-Map=#{tmp_map.p...
^
../../toolchain//scripts/real-ld:77: syntax error, unexpected ']', expecting kEND
../../toolchain//scripts/real-ld:138: syntax error, unexpected ',', expecting ']'
...inker_out.path, *object_files, *call_args]
^
collect2: error: ld returned 1 exit status

Not sure if something is not configured correctly.

need VSS in the header, drop RESET

Imagine cheap USB MCU platform with those properties:

• no SW installation required to develop at PC (ie no drivers installation, no IDE installation, ...)
• IDE in web browser platform independent by design
• powerful libraries to communicate (node-node, node-cloud)
• concurrency tasks without threads

Dream ? May be, but could be feasible.

Well it is a lot of ideas and probably for extra wiki page or more, I will try to explain idea basis.

USB device without driver accessible from JavaScript in browser - USB MassStorage. HTML5 page with IDE can be stored there, it can be used for programming, debugging and data access communication also may be with combination of USB HID by GamepadAPI. So inserting USB MCU platform into PC can open Web browser with IDE. IDE can communicate with MCU throug "special files" or USB HID through Gamepad API.

Because IDE is in web browser, updates of IDE can be straight forward. Imagine that IDE can communicate with github directly ...

For building IDE components can help a lot, e.g. http://codemirror.net/

Storing whole IDE at USB MCU platform would not be problem because large SPI flash can be there.

If platform will support some simple interpreted language like http://www.sics.se/~adam/dunkels06lowoverhead.pdf compiler is not needed, just tokenizer and it can be implemented in browser JavaScript without huge effort.

If simple concurrency would be supported by interpreted language environment, hmmm
E.g. protothreads http://www.sics.se/~adam/dunkels06protothreads.pdf

OK libraries - I leave it for continuation, if there will be any.

What do you think about that ?

it's required by some versions of dfu-util

Maple IDE/libmaple requires USB disconnection ciqruit.
It can be made with one 1.5k resistor or with resistor and PNP transistor
or with USB protection like here:
http://we.easyelectronics.ru/uploads/images/00/22/11/2011/12/27/d14b13.png

The Freescale KL2 Cortex-M0+ will be pin-compatible with the K20. However, it will only come in QFN48.

Need to cut the trace between the MCU regulator output and VDD

Seems the board usb connector is a bit long - we might be able to shorten it by ~3mm.

Hi,

Just noticed that the PCB doesn't have pads for an external crystal (say 16 MHz one). Should we have one? It should be easy to add one between pins 24 and 25.

I think a crystal will be a must if we want reliable USB communication (the internal oscillator in this type of MCUs usually has some drift leading to loss of USB connectivity).

Thanks, Adi

P.S. this is different than the 32.768 kHz RTC crystal for which there are some pads already - but that won't help in this scenario.

make sure number of bits allocated in bitfield is correct

As seen on SparkFun's Arduino Pro Micro: http://datasheet.octopart.com/MIC5205-3.3YM5-TR-Micrel-datasheet-3438.pdf

The regulators on the bottom are a bit close to the mount hole - move to make space for a standoff.

maybe we can buffer the usb serial data until SOF is received, and then package what we have. this avoids sending out 1-byte transfers when we're assembling a larger string char-by-char.

Check if the usb lib properly recovers from dropped packets

Well MC HCK or mchck is hard to pronounce and remember. I know it is a little bit silly issue, but addressing that now can help project to be popular. Contest could be way to right solution ...

Because we're using one fixed port (1234), we can only use one gdbserver at a time.

Required changes: gdbserver.rb, mchck.mk passing port

Feedback from 28c3:

if there is space, put a footprint for an optional data flash IC on the bottom. They are available in up to 64Mbit for SO-8 and could be nicely used for logging or small data exchange.

Seems the system memory (boot loader memory) is write protected, so we can't use it for our own custom boot loader. Therefore the boot selection pins are useless.

we currently use usb_tx_cp, which means we can only deal with descriptors of one transfer or less

Hi!

I interested to buy the MC HCK board. I wanted to know how much it cost with the optional LiPo battery charger IC for battery operation and the optional automatic power source switch between USB, external and LiPo. Also I would like to know a little bit more about this options and more important some specifications. Finally, how can I get it here in Argentina and how much would it cost?

Please contact me at your earliest convenience,

There is a lot of space on the pins under the MCU. Why are these pads so long?

modules like http://www.ebay.com/itm/Perfect-High-Quality-New-NRF24L01-2-4GHz-Wireless-Transceiver-Module-Arduino-/270835646932

We can save a 0R resistor if we put on a default trace that can be cut (no soldermask)

Consider switching GND and 3.3V so that GND and VLIPO wind up next to each other; modify VLIPO so that it can take a standard 100mil header and a 2mm JST battery connector.

There is a great deal of room between the mini-USB connector and the edge of the board. Because of this it is not possible to plug most USB cables into the connector without cutting down the board.

enable placing of MC HCK at SeeedStudio Grove harness - right spaced holes could be enough
http://www.seeedstudio.com/wiki/index.php?title=Starter_bundle_harness_V1.0

Pads for optional 2 or 4 SeedStudio Grove 4pin connectors does not extend PCB so much but adds easy extensibility.