Richard Memory Build Log

Build Log
21

Thinking a bit more, for the second rev of the hardware, I’d like to add a goal to be able to perform JTAG or SWD debugging.

It appears from various forum entries, this isn’t explicitly supported by the currently available Teensy boards (although it seems JTAG support (with a header) might be coming at some point in the not too distant future). For the time being, the primary goal of the Teensy hardware seems to be to support the Arduino IDE, which I suspect is likely the vast majority of Teensy users (I’m likely the oddball here).

I have found one guy who did some serious reverse engineering to be able to use the Teensy 3.1/3.2 with his JTAG, but it requires cutting through the PCB substrate to gain access to certain traces. I’m just not super interested in going to those lengths to support JTAG.

On the Teensy 3.6 on the other hand, it appears there are a couple of pads on the backside of the board intended to support SWD debugging.

In this image, on the back side of the Teensy_3.6, there are pads for DD (Debug Data) and (Debug Clock), and a third called DE (Debug Enable). These are SWD signals. It seems the purpose of the DE pin is to allow an external debug device to pull that signal low, and disable the chip responsible for communicating with the Arduino IDE, essentially allowing the external debug device to take over control.

Unfortunately, it seems the DE pin doesn’t quite yet work as advertised. The following blog provides some additional details on adding debug support on a Teensy 3.6. Summary: It can still be done, but a warranty-breaking removal of the Ardunino communication chip with a heat gun, which I don’t yet own, will be required. I don’t necessarily mind “breaking the warranty”, but I’ll need to find a heat gun.

Attaching Debugger to Teensy 3.6

In other words, the next gen “sensor board”, or whatever it will be called, will be built using a Teensy 3.6 and not the 3.2.

The probe I have been looking at is this one. Its relatively inexpensive.

22

Interesting! You could make a conversion board for the 1bitsy to the CE header. This is the ARM board designed to work with the Black Magic Probe (I had the chance to talk to Piotr about it on TAH)

1 Like
23

That’s good info.

On a related topic, when you get a chance, I’d like to work with you to come up with the specs and requirements for this new board.

24

Cool, I think the main thing would be “take the pinout of the 1 bitsy and hook it up to the CE header” but maybe there’s more? The benefit would be that the sensor board could stay the same. But maybe you mean you want to rework a new sensor board?

25

I’m dreaming big at the moment, with a total rework and lots of ideas :slight_smile:

26

@ChrisGammell (or anyone :slight_smile: ), how do I go about adding a test point to my layout? It doesn’t necessarily seem something that needs to be added to the schematic, and can just be added directly to the layout. I am thinking in terms of a single through hole pin per test point, plus one for ground as well. Presumably I add a through hole pad, which isn’t connected to anything on the schematic, and add it to a particular net?

27

@rmemory,

I add a single 1x1 pin header for a single through-hole test point. There are options for a SMD pad as well. I add it to the schematic and let it flow through annotation, cvpcb, and finally to pcbnew.

I do this as it can avoid confusion later when there are differences between the 3 tools. It also help to visualize the purpose of the test point by showing it in the schematic. You can run into issues if you decide to re-import the netlist in pcbnew. If you aren’t careful, you will lose any of those items you have added to the layout which don’t also exist in the schematic.

That said, you can just “add footprint” in pcbnew if you desire. I wouldn’t recommend it as part of a normal workflow.

28

@hedrickbt, thank you. That is very useful info. I do agree the best practice is to add them from the start in the schematic, for the reasons you mention. Exceptions are not a good “best practice”.

All that said, I figured out the “add footprints” method you mention yesterday, and created my first revision of the layout using that method. However, after reading this, I think I will go back and do it right.

1 Like
29

The board looks nice. I really like the label usage in the schematic too.

2031a05f0a1c82b158bbba9f8281c774118cc434.png621×764 33 KB

1 Like
30

Thanks!

I am pretty excited to try out the 1bitsy and the Black Magic Probe. I don’t yet have a full vision of where this is headed, but I’m excited. For the time being, the next step is to integrate it with my existing sensor board. And from there I plan to create a few iterations of the sensor board, using different and new kinds of sensors, servos, analog sensors or filtering, etc. Eventually, I would like to create a layout which puts everything on a single board (my layout skills are still pretty low-end). I might create a port to Yocto Linux. And I might even switch to a Cortex M0 at some point. The reflow oven is still out there as well to play with. There are endless possibilities to have fun with.

IMHO, for me and my interests, this is sooooooo much more interesting than messing with a Raspberry PI or Beagle Bone. But to each their own. Everybody has their interests :slight_smile:

1 Like
31

I have started a new project. Given Adafruit’s lengthy list of very cool development boards, I am working on a prototype sensor network.

These boards are wonderful for lightweight applications like sensors, and they have a bunch of variants to choose from, with a ton of documentation.

For my network, I am using Lora for wireless communication to what I am calling my Lora Gateway. I am not (yet) using LoraWan.

At the moment, the end nodes, use a Feather which uses the ATmega32u4 and a Lora radio. One end node measures ambient temperature, while another is a simple motion detector (I am keeping it simple for the initial prototype).

Each node has its own unique Lora address, and communicates back to the gateway. I am using a “send with ack” mechanism. Here is the Lora stack I am using which includes drivers and packet manager.

For my so-called Lora Gateway, I am using a Cortex M0 based Feather which includes a WiFI chip, and a separate Lora radio which connects to the board using SPI.

As the gateway receives Lora packets from each sensor, it re-packages them into an MQTT packet, and forwards it to a public MQTT server (broker) at Adafruit. Likewise, the MQTT server can send data to the Lora Gateway.

Both Lora and MQTT are designed for low bandwidth applications only (no video and no audio). But they both work well for any application I have in mind. And the range of Lora is impressive (some are reporting ability to transmit over 20km distances).

Lots of questions still to be answered, but its fun.

3 Likes