Full Version: PADUINO Padi Stamp Photo Blog with SWD and CH340g
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
This photo blog will discuss the Padi Stamp ( RTL8710AF ) as PADUINO ;  in addition we'll talk about the two 'sonic screw-drivers' of the embedded world,  namely the CH340g serial usb to TTL bridge adapter ( serial console cable ) and the J-Link OB SWD debugger programmer ( in this case the STM32 F103 ).  All of these devices are ( or will be ) carried on the Pine store.

In addition we'll be talking about programming the RTL8710 ( SDK ) using the Arduino IDE, and using the SWD programmer.  RealTek has decided to support the Arduino IDE , so this is an exciting time for the Padi Stamp and the upcoming PADUINO, which uses the RealTek RTL8710AF;  note:  the Arduino IDE is also supporting the RTL8195A,  the big brother to the RTL8710AF.

[attachment=1026]   [attachment=1025]

In the pics above you can see the fore-runner prototypes of the formal PADUNIO;  I called these hats Padi-dunio shields -- or POT(s) position on top.  They were designed to be plugged into the Arduino Uno, Due, or Mega2560 to provide the Arduino with much needed wifi support.  As you will see later on (below), the PADUINO combines the two ideas nicely to form a new offering from Pine; the PADUINO.

The pic at left shows the two POT experimental prototypes, while the pic at the right details the connections for the J-Link OB SWD programmer and the CH340g serial usb console adapter, plugged into the 'maker' shield prototype.

CH340g Serial Console

The Padi Stamp has two active uart consoles out-of-box;  the command console on [ A_0, A_4 ] and the log console on [ B_0, B_1 ].  Both consoles are I|O, and both consoles are used together to control the Padi either from an interactive user stand-point, or via AT command set within an external MCU ( in this case the Arduino ). For simplicity sake I have only connected the 'Log Console' in the pics above.  Think of the log console as a system log, except that it can accept commands too!

The CH340g allows us to communicate interactively with the Padi Stamp ( or PADUINO ) to either of the active uart consoles.   In addition the Arduino IDE can upload sketches to the Padi Stamp via log console input ( although, this is not working correctly at the moment of this writing ).  The CH340g requires a driver on Windows, and also on the Mac.  It works out-of-box on gnu+linux usually.  The PADUINO (shown later) has an on-board CH340g chip connected directly to the log console;  consequently the external CH340g is normally connected to the command console, not shown.

J-Link OB SWD Programmer Debugger

The J-Link OB SWD programmer debugger is an interesting creature!  Its a simplified J-Tag programmer utilizing the STM32 F103 MCU in the SWD format ( Single Wire Data ). In the embedded world on-board programming and debugging is normally accomplished with J-Tag ( a proprietary and expensive protocol for talking to the hardware of the CORTEX-M3 live ) !  The J-Tag protocol requires five (5) lines minimum ;  although, the SWD protocol simplifies this down to three (3) lines :  ground,  SWclk (clock), and SWDIO ( single wire data input | output ).  

The SWD debugger from Pine store has four lines :  red:Vcc 3v3,  black:ground,  blue:SWclk,  green:SWDIO

On the Padi Stamp ( also PADUINO ) the J-Tag pins are E_0 to E_4;  with SWclk going to JTAG_CLK on E_4, and SWDIO going to JTAG_TMS on E_3.   These connections are detailed on the pics I'm providing today.  The interesting thing with SWD (single wire data) is that the same wire is both input and output to|from the CORTEX-M3 on the Padi!

When we connect with the JLinkExe software from Segger, we will select the S option for SWD protocol rather than the J option for J-Tag.


In the pic above you can see the PADUINO prototype board from Pine!  With the PADUINO pictured here, I also have the SWD debugger 'blue' SWclk connected to JTAG_CLK E_4, and the 'green' SWDIO connected to JTAG_TMS E_3.  As well, both uart consoles are connected on this diagram pictured;  please note the on-board CH340g which connects the on-board USB connector directly to the log console of the Padi Stamp (RTL8710AF) on B_0, B_1.  

The external CH340g is connected to the Padi command console on A_0, A_4;  in this pic the PADUINO is getting power from the Mac connected to the USB jack.  Both CH340g adapters are connected to the Mac via usb hub (powered, from Belkin).

If you are familiar with the Arduino Uno, this PADUINO should at least feel comfortable;  the form factor and header pinouts are identical.  In fact, my maker shields plugged in with no effort and the pinouts 'make sense' for the maker community.

J-Link SWD and the Segger JLinkExe Software

Before exiting this segment, I'm going to talk a little more about the J-Link SWD and the Segger software used to talk to the CORTEX-M3 on the Padi.  


Please reference the screen shot above;  this is the result of connecting to the Padi CORTEX-M3 with JLinkExe and the J-Link OB SWD programmer.  I obtained the the software package v1.68d from Segger. After using JLinkSTM32 to reset the SWD,  I used these commands from JLinkExe to connect to the Padi via SWD:

JLinkExe :   this command is the main SWD program, also used for uploading | downloading.

JLink>  connect       I just hit enter for default type of CORTEX-M3

TIF>  S               sets the SWD mode of the debugger

SPEED>              I just hit enter for the default of  4000 kHz

     Found SW-DP with ID 0x2BA01477       ( see screen shot above )

JLink>  ?             will give you a list of commands ;  please see the handbook

JLink>  qc          drops the connection and exits the JLinkExe program

While the CH340g allows us to speak to the Padi from a 'console' standpoint,  the SWD allows us to speak to the Padi from a hardware MCU standpoint;  including, but not limited to, uploading programming into the Padi Stamp!

A little story about J-Link and Segger

This is an important addendum really, and something that you should be aware of from a political, legal, and technical standpoint.  The Segger software is commercial software supplied to be run on their commercial products, some of which are very expensive.  The official commercial debugger ( J-Link ) from Segger is about $700 dollars usd. The education version is on the order of $70 dollars usd;  just to show orders of magnitude.  On the other hand, the SWD debugger from Pine store is about $7 dollars usd.


I used the JLinkSTM32 program to reset the SWD and update its firmware;  this may have been a mistake, everything is too new (for me) to know yet.  Please refer to the screen shot above;  you will note that there is an error message which states generally that 'this' J-Link SWD is defective !  It prompts me to report this to Segger with a screen shot in my email showing serial number and so on and so forth.    hmm

This error occurs for 'every' program in the Segger suite of J-Link tools almost precisely five (5) seconds after invoking the program;  from then on, the program appears to function properly without difficulty, and the J-Link SWD OB programmer appears to function normally.  The question this raises is, is this SWD actually defective, or is this grumpy-ware because the software has detected that it is running on unofficial hardware ?  Or, is the hardware not able to support all options of the J-Link software ??   

I suspect the latter.  Other individuals have reported the very same messages on their J-Link STM32 F103 devices ( including the device from Pine ) beginning with about Segger v614a of the software.  I may ( just for grins and giggles ) acquire on official educational J-Link from Segger ( $70 dollars usd ) for testing and verification of this theory.  Just be aware;  we are discovering yet another example of why software must be free and open. 

If others find a free version of J-Link software for the SWD J-Link OB programmer from Pine ( STM32 F103 ) feel free to post here.


Stay tuned;  further posts will continue with the PADUNIO; not only the SDK (with SWD programmer) but also the Arduino IDE.  Should be a fun and exciting time.
[attachment=1028]   [attachment=1029

This segment is a side-bar to show you what I'm using for my padi_lab power source.  A particular challenge for the PADUINO is to provide a safe comfortable power supply which is more|less Arduino compatible ( at least similar ) that will have both 3v3 and 5v rails with regulation ( whether linear or switching ).  The prototype supply on my PADUINO board over-heated and burned out; sadly !  

The pic to the right above is the close-in shot of the elego breadboard power supply;  DCIN is 7v to 12v @ 500ma or more.  The regulators and power distribution is detailed in the pic to the left above.

My padi_lab is being powered via 9v 300ma transformer into DCIN;  both Padi Stamps are being powered ( with wifi active ) from the same source;  runs cool and although the 5v rail is low has a good strong 3v3 source;  the 5v rail will improve with a stronger transformer or higher.

The elego supply has been a brilliant addition to my lab and has been a source for many breadboard projects requiring either regulated 3v3 or 5v rails !  It has been a life-saver in the padi_lab because the supplies built-in to most serial uart adapters is not sufficient to power the padi with the wifi active !

Note:  as a side comment, the pic upper left points out the uart switch board of my padi_lab breadboard.  Both consoles of each padi are brought together in one location with Tx:Rx together as a consistent two prong plug -- similar to an old style telephone switch board;  the uart console can be chosen easily by moving the two prong plug to the desired patch-panel position without having to hunt for the uart numbers, and without having to shutdown the console terminal emulator ( in my case using cu on either my mac, or on my Pinebook ).  On the PADUINO, the console pins from the Padi Stamp MCU could be jumpered so that they are either connected to the header pins , or so that they are connected to the on-board CH340g or simulated patch panel.
[attachment=1034]   [attachment=1035]   [attachment=1036]

This proto-board had a bad cap (C6) and a small design flaw;  the cap broke down, shorted out, and got red hot;  even smoke and burned my finger ( I've always got to touch stuff )     Tongue

Anyway, I pulled the cap and replaced it.  You can see the classic leaky puffed out bottom on the old cap;  the new cap is a little tall, but for this prototype I don't care.  

The small design over-sight is the usb power take-off on the log console port !  There is no isolation diode in the main supply circuit to protect the 8292 and L2 inductor from current backfeed -- which causes the power supply section of the board to become a load and over-heat !

I got around the backfeed problem with a modified usb cable;  I can power with DCIN ( 9v ) and still use the log console on the usb jack because I've isolated the vcc_bus 5v line from the 5v rail.  The production board needs an isolation diode ( 1N5819 ) just after the L2 inductor in the VIN power circuit.

Anyways, I'm back to experimenting with the PADUINO in an effort to get the Arduino IDE working with it.  Stay tuned...   should be fun.


We're back in business !   ... PADUINO ran all night ( on the network ) cool as a cucumber;   I got to thinking, TL Lim, the diode should be a part of the optional 5v circuit, and that circuit should not be optional !   Talk it over with the engineer;  the optional circuit may really need to be applied.


In this setup I have reversed the experiment;  I am powering both Padi Stamps ( wifi active on the network ) from the switching supply circuit on the PADUINO--  cool as a cucumber, 3v3 steady at 3.221 ( very nice ).  The real point of this experiment is to test the RT8292 under fluctuating load to determine if it was damaged by back-feed and over-heating;  apparently not-- tough little chip!


In this segment I'm going to talk a bit about the Arduino built-in LED(s).  The PADUINO has only one LED which is a 3v3 power indicator.  All other Arduino boards have a set of built-in LED(s) which include the LED_BUILTIN pin(13), and the Tx Rx uart comm LED(s) for at least the log console.  

The PADUINO production board needs to have uart comm LED(s) for the log console, and the log console pins on the padi ( B_0, B_1 ) need to be jumpered between the header and the CH340g!

Also, the primary discussion for the rest of this segment, the PADUINO production board needs to have the LED_BUILTIN installed on the main board;  however, I would also jumper this LED, which IMO is a significant configuration enhancement over other Arduino boards.

In the pic above you can see the power LED (red) but notice that there is no LED_BUILTIN ( is normally yellow, but color is not important ).  Also notice that I have setup an optical coupler to drive a power LED from the 5v rail ! As you can see--  three wires, breadboard wiring, external resistors;  let's just agree its messy !  ( there is a better way )

So, I'm going to demonstrate my point(s) with a proto-shield that I've been working on for the PADUINO which addresses some of these concerns -- as much of this as can be placed on the main production board, the better !

[attachment=1042]   [attachment=1043]

In the pics above you can see that the LED_BUILTIN ( gorgeous blue ) and the optical coupler have become integral components on the main board ( albeit, on the proto-shield ).  The components are jumpered to Arduino pin(13), padi PC_1. The center jumper pins connect to pin(13) PC_1, and the outside pins attach to the optical coupler ( yellow jumper left ) and the LED_BUILTIN ( green jumper right ).  Either one, or both, of the jumpers may be used together or individually with the following commands from the log console :

   ATSG=W,PC_1,1,1    < sets ON >

   ATSG=W,PC_1,0,1    < sets OFF >

The benefit of the LED_BUILTIN is that without any external wiring what-so-ever, the PADUINO may be tested with the Arduino IDE allowing the new user to get comfortable with the board and the IDE without having to be concerned about breadboarding or external components!  The pic to the right shows a detail of the 4N35 optical coupler ( white plastic block ) and the pin(13)  Padi PC_1  jumpers.  The optical coupler provides isolation -- is essentially an NPN photo transistor with a trigger LED in one package.  Setting on the package LED (which is not visible) turns on the photo transistor allowing current to flow in an isolated circuit.  I have also jumpered the base of the optical coupler transistor as well the collector of the optical coupler for easy access.

[attachment=1041]   [attachment=1039]

In the pic above left the pin(13) jumper is in the opto-coupler position left. PC_1 now triggers the optical phototransistor in the 4N35 and the external power LED (higher current) is driven ON via the 5v rail -- this requires isolation of some kind , because the logic of the padi is 3v3 !

The pic above right shows the LED_BUILTIN jumper in place, as well the optical coupler is now being triggered by Arduino pin(12)  Padi PC_3  using a small jumper wire rather than the two pin jumper connector.  Clearly the wiring is cleaner, easier, and more versatile. 

Note:  the proto-shield from the Arduino people is fantastic;  it has extra long pins so that the shield essentially has two layers ( top, bottom ) with plenty of room for components either side.  This was helpful for me also, in that the taller cap (C6 replacement) fit well under the shield without difficulties. This particular proto shield will also be populated with two shift registers, a motor driver, and a relay driver.  

(09-08-2017, 12:26 PM)That Segger stuff hosed my J-Link firmware without warning!! . Wrote: [ -> ]Hi Mark - I think you should update this post to CLEARLY warn us **BEFORE** we follow your instructions, that the Segger software is going to wipe out our J-Link firmware without warning upon first run !!