Sometimes you don't have access to module programming port when it's embedded in the middle of the array and you don't want to use the SWD pins; Or sometimes you design your array so that programming ports are connected to other ports; Sometimes you're just feeling lazy and don't want to connect to each module to update its firmware! For all these cases, we added a feature to remotely update a module via nother one using ST factory bootloader and the ST Flash Loader Demonstrator tool. Check this article for a review of all firmware update methods in Hexabitz.

Usage

The same command used for normal bootloader update is used for remote update. There are two basic forms:

#3.update

where you remotely update module 3 via another module. Note in this case module programming port (marked with asterisk) must be in the shortest path to the module. Example of this is updating module 2 in the array before while connecting to module 1, port 1. 

The other format (via-port remote update) is:

update via #3 p5

where you remotely update the module that has its programming port connected to module 3, port 5. This format is useful in two situations:

• If the module you want to program is not part of the array topology (so it doesn't have an ID and topology). Similar case happens when the module doesn't have a firmware)
• If the module programming port is not the shortest path from where you are sending the command. Example of this is updating module 3 or 6 via module 1 in the array below. Programming ports are marked with red circles. It can be seen that shortest path from module 1 to module 3 ends up in port 3 of module 3 which is not the programming (factory bootloader) port. In order to reach port 2 of module 3, you can use the command: 

  update via #4 p3

Note: After remote updates, you need to power cycle the entire array to restore normal operation.

How does it work?

The remote update command backend stacks serial ports and DMA streams to construct a bidirectional pipeline between the the port connected to ST Flash Loader tool and the programming port of target MCU (which will be running ST factory bootloader through that port). However, few things must happen first, in the correct order, before a successful connection:

1. The source module sends a message to target module asking it to jump to its bootloader. In the remote update format #n.update, n is the target module. In the remote via-port update format update via #n pm, the target module is the one connected to module n, port m. Note that if you want to update firmware on an empty module (or one that doesn't run Hexabitz firmware) that is not in its bootloader mode, you must force it into that mode.
2. Baudrate for all involved serial ports must change to 57600 to be compatible with ST bootloader settings.
3. Parity for all involved serial ports must change to EVEN to be compatible with ST bootloader settings.
4. The last port before the target must swap its pins since the serial port in ST bootloader will restore its normal pinout configuration.
5. Finally a bidirectional DMA stream must be established. The stream is setup with infinite timeout and number of bytes. Thus, once you're done with the update you must power cycle the array to restore everything to normal operation.

Examples

The video below shows a step-by-step guide of remote updating module 2 in the array above from module 1, port 1. 

This video demonstrates successful remote bootloader update of module 6 in the array above from module 1, port 1. Module 6 is three MCUs away from the ST Flash Loader tool!

Many of you asked about proto board modules to make your own customized, Hexabitz-compatible modules! Well, the wish came true :D We just released our first batch of proto board modules (both TPH and SMT) more designs coming later.

Let us know what cool stuff you'd build with them!

https://hexabitz.com/product-category/modules/

H00R40 - 100-mil TPH Proto Board

H00R40 is a through-hole proto board module with 100-mil plated hole pattern. Use this module to prototype any circuit you want and add it to your Hexabitz collection! The module features a 1-mm plated drill pattern with 100 mil spacing. Six array and six power ports are available to seamlessly integrate with Hexabitz ecosystem. Power ports are separate from each other, in case you need multiple voltage rails in your array.

H00R50 - 100-mil SMT Proto Board

H00R50 is a surface-mount proto board module with 100-mil pad pattern. Use this module to prototype any circuit you want and add it to your Hexabitz collection! The module features a 92-mil-by-92-mil SMT pad pattern with 100 mil spacing. Six array and six power ports are available to seamlessly integrate with Hexabitz ecosystem. Power ports are separate from each other, in case you need multiple voltage rails in your array.

H00R60 - 50-mil SMT Proto Board

H00R60 is a surface-mount proto board module with 50-mil pad pattern. Use this module to prototype any circuit you want and add it to your Hexabitz collection! The module features a 42-mil-by-42-mil SMT pad pattern with 50 mil spacing. Six array and six power ports are available to seamlessly integrate with Hexabitz ecosystem. Power ports are separate from each other, in case you need multiple voltage rails in your array.

Array exploration is a feature that lets automatically configure your Hexabitz arrays and generate their topology without a sweat. It is particularly useful for large and complex arrays where manually generating the topology is usually cumbersome and error-prone.

Once you assemble your array and program all modules with native firmware, You can invoke the array exploration algorithm via the Explore() API or explore CLI command. The algorithm finds out number of connected modules (N), the topology routing table (stored in array matrix) and which ports are swapped. All of these information are stored either in the emulated EEPROM or a special Flash page so that you don't have to explore again every time you reboot the array. Note that the module you're connected to when invoking the exploration algorithm will be assigned ID #1. Other modules will be assigned sequential IDs based on their relative distance to the master (module #1).

Exploration Algorithm

Here's a detailed step-by-step description of what happens in the exploration algorithm:

1. The master module (ID #1) swaps all its ports and explores adjacent neighbors by sending them an inquiry message. Neighbors send back a response mentioning which port they heard the inquiry from. 
2. The master then starts assigning IDs to new modules and updating its topology array:
   1. Assign sequential IDs to neighboring modules (according to master ports they're connected to).
   2. Update the master topology array with IDs and ports of neighboring modules.
   3. Ask neighbors to update their own topology array.
3. The master asks each new module to explore its neighbors, basically repeating steps 1 & 2. This continues level by level until all modules are explored:
   1. Master asks a given module to swap its ports
   2. Master asks the module to explore its adjacent neighbors.
   3. Master assigns IDs to this module adjacent neighbors.
   4. Master updates its topology array.
   5. Master asks all discovered modules to update their topology array as well. Then the master repeats steps 1 to e asking next module down the list to explore.
4. The master ensures all connected modules have been already discovered by reissuing exploration commands to all modules and watching out for any new un-IDed modules.
5. If there are no un-IDed modules, the master generates and distributes appropriate port directions:
   1. Virtually reset the state of master ports to Normal.
   2. Update other modules ports starting from the last one and going backwards to ensure the communication chain is not broken.
   3. The master asks each module to update its port direction.
   4. The master officially updates its ports back to normal.
6. The master tests new port directions by pinging all modules and recording their responses. It's also displayed on the terminal if the CLI explore command was invoked.
7. The master asks all modules to save the topology and port directions in specific Flash page (for topology) and emulated EEPROM (for number of modules and port directions).

The following video shows exploration of different arrays with various shapes and complexities. There are generous delays currently in the algorithm making it a bit lengthy (2 minutes for the sphere) but they can be optimized later.

Removing Current Topology

If you want to reconfigure the array in a different shape without erasing and reprogramming modules, you can invoke the CLI command default array to remove topology related information from Flash / emulated-EEPROM. Remember to do that before disassembling your array!

H04R10 / H04R20 are compact coin-cell lithium battery holders that fit two CR2032 batteries in parallel (H04R10) or in series (H04R20).The output voltage is provided through Hexabitz SMD edge-pad connectors (3.0V in H04R10 and 3.3V in H04R20 on top and GND on bottom).

Note 1: H04R10 was named H13R00 before. 

Note 2: H04R20 was named H13R10 before. 

Note 3: These modules do not ship with coin-cell batteries.

Technical Specifications

• 2 x CR2032 lithium coin-cell battery holders in parallel (+3.0V output) in H04R10.
• 2 x CR2032 lithium coin-cell battery holders in series (+3.3V output) in H04R20.
• Six power ports (+3.0V/+3.3V and GND).
• 2 x BLP2032SM-GTR SMD coin-cell holder with gold-plated contacts.
• H04R10: BAT54JFILM 40V 0.3A reverse current protection Schottky diode. (Can be shorted with a solder jumper.)
• H04R20: TPS76433DBVT 3.3V 0.15A LDO.

Physical Properties

• Shape: Hexagon
• Size: 3 cm short diagonal
• Area: 7.8 cm^2
• Soldermask Color: Dark green
• Finish: ENIG (gold) or HASL-LF (tin)

Documentation

• Module factsheet. (Note: More module options will be listed later.)

Design Files

• H04R10 schematics [PDF]
• H04R20 schematics [PDF]

FAQ

Q: How much current do I get from a single H04R10?

A: Most CR2032 coin-cell batteries are about 200mAh capacity with a standard discharge current of 0.2mA. With two in parallel, you can get up to 450-500mAh of each H04R10 module.

Q: What happens if I have another higher voltage source in my board?

A: There is a reverse protection Schottky diode on H04R10 that prevents current from flowing back into the coin-cell battery in case you have higher voltage (e.g., 3.3V or 5V) applied at the same time. Note that although Schottky diodes have low forward voltage drop, the drop can reach 300mV at the above battery discharge rate. To avoid having a lower output voltage (3-0.3 = 2.7V), you can short the reverse protection diode on H04R10 with a solder jumper.

Q: How much current do I get from a single H04R20?

A: Most CR2032 coin-cell batteries are about 200mAh capacity with a standard discharge current of 0.2mA and voltage of 3V. With two in series, you can get same capacity but double the voltage. The voltage is regulated back down to 3.3V to be compatible with other Hexabitz modules. You can also solder H04R20modules together, connecting them in parallel, to get more capacity.

---

Projects

H1BR60 is a nifty little SPI-based, micro-SD card module based on STM32F0 MCU and running Fatfs file system. It is part of the upcoming Hexabitz modular prototyping system.

• Use as a stand-alone data-logger or easily integrate with other hardware via serial interfaces.
• Setup and control logging via a Command Line Interface (CLI).
• Log digital inputs, memory locations, program variables, serial streams and button actions.
• Start multiple simultaneous logs with different log variables each.
• Firmware has Fatfs embedded file system and advanced logging functionality (event logs, rate logs, sample-based, time-based, sequential naming, etc.)
• Supports SDHC micro-SD memory cards (FAT32, up to 32GB size).
• Program advanced C code with our easy-to-use APIs.
• Connect to external hardware or combine with other Hexabitz modules!

Note 1: This module was named H05R00 before.

Note 2: This module does not ship with a micro-SD card.

Technical Specifications

• Five array ports and four power ports (+3.3V and GND).
• Access to 5xUART, 1xI2C, SWD, BOOT0, RESET.
• SPI-connected microSD memory card for SD and SDHC cards with full integration of Fatfs file system.
• Molex 502570-0893 microSD push-push connector with card detection.
• STM32F091CBU6 MCU.
• 8MHz external oscillator.

Physical Properties

• Shape: Hexagon
• Size: 3 cm short diagonal
• Area: 7.8 cm^2
• Soldermask Color: Dark green
• Finish: ENIG (gold) or HASL-LF (tin)

Documentation

• Module factsheet

Design Files

• Module schematics [PDF]

Source Code

• H1BR60 module code [repository]

FAQ

Q: How do I use H1BR60 to add logging capability to my projects?

A: H1BR60 module logs all sorts of signals connected to its array ports. You can stream digital data from external hardware using serial ports (UART), connect digital sensors (3.3V max) directly, connect external switches of any type (mechanical, optical, magnetic) or momentary and toggle buttons.

Q: Can I log same signal in different ways?

A: Yes! You can start two simultaneous logs of different types (rate or event) and log same or different signals.

Q: Can I log a complicated condition/combination of signals?

A: Yes! You can write C code to combine signals in complex ways and write the output to an internal RAM buffer. This buffer / memory location can then be logged either on rate- or event-basis.

Q: What's the maximum logging rate in H1BR60?

A: Maximum logging rate is 1KHz. However, it depends on number of simultaneous logs and number of variables per log. Usually it is several hundred Hz in complicated scenarios.

---

Projects

H0FR60 is a compact solid state relay (SSR) module capable of driving AC loads up to 600V and 1.2A. It is based on Panasonic AQH3213A SSR and STM32F0 MCU. It is part of the upcoming Hexabitz modular prototyping system.

• Use as a stand-alone smart AC relay and easily control AC loads (lamps, fans, power outlets, etc.) via a Command Line Interface (CLI).
• Firmware has embedded on / off / toggle, timers and PWM functionality.
• Program advanced C code with our easy-to-use APIs.
• Connect many H0FR60 modules together and build interesting flat and curved boards with any configuration you imagine!
• Send commands to a single relay, a group of relays or broadcast to all of them.
• Connect to external hardware or combine with other Hexabitz modules!

Note: This module was named H09R00 before.

Technical Specifications

• Five array ports and six power ports (+3.3V and GND).
• Access to 5xUART, 2xI2C, SWD, BOOT0, RESET.
• Panasonic AQH3213A solid-state relay (SSR):
• 120V or 240V AC rated voltage.
• 600V AC peak OFF-state voltage.
• 1.2A ON-state RMS current.
• 100 µsec maximum turn-on time.
• Zero-crossing detection.
• Yellow indication LED for SSR state.
• SSR load connector: TE Connectivity/AMP 2-position 5.08mm shrouded header.
• STM32F091CBU6 MCU.
• 8MHz external oscillator.

Physical Properties

• Shape: Hexagon
• Size: 3 cm short diagonal
• Area: 7.8 cm^2
• Soldermask Color: Dark green
• Finish: ENIG (gold) or HASL-LF (tin)

Documentation

• Module factsheet

Design Files

• Module schematics [PDF]

Source Code

• Coming soon!

FAQ

Q: What types of loads you can switch with this SSR?

A: All sorts of AC loads < 700 watts including lamps, fans, heaters, power outlets, AC synchronous motors, etc. You can also switch DC loads in the same range (but this SSR will not stop a DC load going the other direction unless you turn it off).

---

Projects

H03R00 is a compact DC-DC buck power supply with a 3.3V/1A DC output and 5-40V DC input. The output voltage is provided through Hexabitz SMD edge-pad connectors (3.3V on top and GND on bottom). The -T module version comes with a 5.08mm terminal block connector for input voltage. This module is part of the upcoming Hexabitz modular prototyping system and can be used to power all your Hexabitz arrays as well as other hardware.

Technical Specifications

• Input voltage: +5V to +40V DC.
• Output voltage: +3.3V DC.
• Output current: 1A.
• Six output power ports (+3.3V and GND).
• TI LM2575SX-3.3/NOPB high-efficiency, 1A, step-down, switching voltage regulator:
• 52 kHz Fixed Frequency Internal Oscillator.
• Thermal shutdown and current limit protection.
• Green power-OK LED.
• Input voltage connector: TE Connectivity/AMP 2-position 5.08mm shrouded header.

Physical Properties

• Shape: Hexagon
• Size: 3 cm short diagonal
• Area: 7.8 cm^2
• Soldermask Color: Dark green
• Finish: ENIG (gold) or HASL-LF (tin)

Documentation

• Module factsheet. (Note: More module options will be listed later.)

Design Files

• Module schematics [PDF]

FAQ

Q: How many Hexabitz modules I can power from a single H03R00?

A: Depends on type of modules connected but usually 40+ modules can be powered from a single H03R00.

Q: How can I access output voltage for non-Hexabitz hardware?

A: You can solder wires and many types of connectors to the SMD edge pads. Our favorite one is the 2-pin 2.54mm male header which fits there perfectly but other connectors are also possible.

Q: Can I combine multiple H03R00 modules on parallel to get higher current?

A: Theoretically you can do so as the edge PCB connectors are perfect to connect modules on parallel. However, be careful as sometimes small variations in output voltage might cause current to flow from one power supply to another. We will have in the future dedicated modules to handle load-sharing between power supplies!

---

Projects

H01R00 is a smart RGB LED module based on Cree CLVBA-FKA-CC1F1L1BB7R3R3 RGB LED and STM32F0 MCU. It is part of the upcoming Hexabitz modular prototyping system.

• Use as a stand-alone smart RGB LED and easily control via a Command Line Interface (CLI).
• Firmware has embedded on / off / toggle, PWM, dimming and color sweep functionality.
• Program advanced C code with our easy-to-use APIs.
• Connect many H01R00 modules together and build interesting flat and curved boards with any configuration you imagine!
• Send commands to a single LED, a group of LEDs or broadcast to all of them at the same time.
• Connect to external hardware or combine with other Hexabitz modules!

Technical Specifications

• Six array ports and six power ports (+3.3V and GND).
• Access to 6xUART, 2xI2C, SWD, BOOT0, RESET.
• Cree CLVBA-FKA-CC1F1L1BB7R3R3 RGB LED:
• Dominant Wavelength: Red (619 - 624nm) Green (520 - 540nm) Blue (460 - 480nm).
• Luminous Intensity (mcd) @IF=20mA: Red (224 - 560) Green (280 - 900) Blue (90 - 355).
• STM32F091CBU6 32-bit ARM Cortex-M0 MCU.
• 8MHz external oscillator.

Physical Properties

• Shape: Hexagon
• Size: 3 cm short diagonal
• Area: 7.8 cm^2
• Soldermask Color: Dark green
• Finish: ENIG (gold) or HASL-LF (tin)

---

Documentation

• Module factsheet

Design Files

• Module schematics [PDF]

Source Code

• H01R00 module code [repository]

FAQ

Q: Isn't a 32-bit MCU an overkill for a smart LED module?

A: Yes! But all Hexabitz modules -whether it's a complex Ethernet or IMU or a simple LED- share same backend hardware and software. This what gives the platform its unmatched modularity and scalability. Cortex-M0 MCUs are small, cheap, power-efficient, yet capable of really wonderful things. Having an embedded MCU provides a cheaper and more compact alternative to connecting an LED breakout with an external controller.

Q: What level of soldering experience is required?

A: Hexabitz are designed for the absolute soldering beginners! The edge pads are large and easy to reach and anyone with basic knowledge of soldering can assemble a flat array. Curved and spherical arrays require more training but can be made easier with 3d-printed fixtures.

---

Projects

Each programmable module has a real-time clock (RTC) and calendar that can be used to track time and date. The module will maintain an accurate internal time and date as long it is powered from a power source or battery and the initial time and date were setup correctly.

Current time and date can be accessed anywhere in the project by calling the GetTimeDate() API and reading the global BOS.time and BOS.date structs:

BOS.time.ampm      // Current time in 12-hour format: RTC_AM or RTC_PM
BOS.time.msec      // Milli-seconds: 0-999
BOS.time.seconds   // Seconds: 0-59
BOS.time.minutes   // Minutes: 0-59
BOS.time.hours     // Hours: 0-23
BOS.date.day       // Date: 1-31
BOS.date.month     // Month: JANUARY (1) to DECEMBER (12)
BOS.date.weekday   // Weekday: MONDAY (1) to SUNDAY (7)
BOS.date.year      // Year: Starting from 2000

You can setup the hour format (12 or 24) and calendar daylight saving settings (DAYLIGHT_SUB1H, DAYLIGHT_ADD1H, or DAYLIGHT_NONE) from the BOS.hourformat and the BOS.daylightsaving parameters, respectively. The settings will be saved in the emulated-EEPROM and loaded on startup.

The RTC takes firmware compile time and date as the initial time and date by default. You can reset the initial time and date via the BOS_CalendarConfig() API. Even if the MCU was hardware-reset, it will keep its current initial time and date (and thus maintain time and date accurately) as long as it is powered. Once it loses power, it returns to the default firmware compile time and date and the RTC must be reconfigured again.
To display current time and date in the CLI, use the time and date commands. You can also configure the RTC in the CLI via the set command.

BOS offers a powerful remote memory read/write access functionality through specific Messages and APIs. This allows a module to access and modify almost any RAM or Flash memory location in another module in the array thus providing powerful synchronization and granular control.

BOS Variables

Typically, you will need a valid memory address to read a variable stored in RAM (e.g., 0x20000100) or Flash (e.g., 0x08000100). In order to simplify the process, BOS defines a set of RAM-based BOS Variables that you can use to easily exchange small amount of data across the array. BOS Variables can be addressed with easy-to-use virtual addresses (1 to N) without the need to know their actual RAM location. For example, you can link a float (or any other datatype) value to BOS Var 1 and access it from any other module in the array. There is a maximum number of bytes that each module reserve for BOS variables. It is defined in MAX_BOS_VARS preprocessor constant. If MAX_BOS_VARS=100, then you can define 100 1-byte variables, or 25 1-word variables and so forth.
The following examples demonstrate how to define BOS variables. Using the keyword volatile in front of a variable definition tells the compiler that this variable might change outside the program (e.g., by a remote module):

// LED state (ON/OFF), intensity and color (global or static if inside a function)                            
volatile bool state = true;                 
volatile uint8_t intensity = 50, color = WHITE;    

// Link to BOS variables (inside a function)    
AddBOSvar(FMT_BOOL, (uint32_t) &state);
AddBOSvar(FMT_UINT8, (uint32_t) &intensity);
AddBOSvar(FMT_UINT8, (uint32_t) &color);

The API AddBOSvar() accepts the following datatypes:

FMT_UINT8
FMT_INT8
FMT_UINT16
FMT_INT16
FMT_UINT32
FMT_INT32
FMT_FLOAT
FMT_BOOL

and returns the BOS variable index (or virtual address) or 0 if memory is full.
Note 1: BOS variables must be defined as global (e.g., outside a function) or static to ensure we do not reference a temporary variable within a function stack.
Note 2: When using direct Flash and RAM addresses, pay special attention to memory alignment. Cortex-M0 MCUs do not accept non-word aligned memory access, which results in a processor Hardfault.

Remote Read

Use the ReadRemoteVar() and ReadRemoteMemory() APIs to read a remote module BOS variable or memory location. The first one returns a pointer to the remote value as well as a pointer to the remote BOS variable format. The second API only returns a pointer to the remote value. The remote format here should be specified by the local module since a memory location can contain any datatype. Note that the returned pointers must be casted to the correct datatype before their addressed value can be read correctly. The following examples demonstrate the proper use of these APIs:

volatile float myremotevar = 0;
// Reading remote address 0x2000001c from Module 2 with FLOAT format and 1000ms timeout
myremotevar = *(float *)ReadRemoteMemory(2, 0x2000001c, FMT_FLOAT, 1000);

volatile bool mybool;
varFormat_t format1;
/* Reading remote BOS variable 1 from Module 2 with 100ms timeout. Remote format is requested and stored in format1. It can be used to cast the variable properly in case we don't know the format beforehand */
mybool = *(bool *)ReadRemoteVar(2, 1, &format1, 100);

Both read APIs will block until the read value is returned or timeout reached (in which case a NULL pointer is returned). If he requested remote BOS variable does not exist, the APIs return BOS_ERR_REMOTE_READ_NO_VAR.

Remote Write

The API WriteRemote() is used to write to both a remote memory location or BOS variable. Setting up the remoteAddress parameter to any value between 1 and MAX_BOS_VARS writes to a BOS variable while setting it up to a valid RAM or Flash location writes to this location. If the BOS variable does not exist, a new one will be created in the remote module. The remote format is always specified by the local module. The following examples demonstrate the API usage:

volatile bool mybool = true;
/* Writing the value of mybool to remote BOS variable 1 in Module 2 with a BOOL format and 0 timeout, i.e., skipping confirmation */
WriteRemote(2, (uint32_t) &mybool, 1, FMT_BOOL, 0);

volatile uint32_t mynum = 0x12ABCDEF;
/* Writing the value of mynum to remote address 0x08016000 in Module 2 with UINT32 format and 100 timeout */
WriteRemote(2, (uint32_t) &mynum, 0x08016000, FMT_UINT32, 100);

A remote write with non-zero timeout will block until a confirmation Message is received or timeout reached. A zero timeout disables sending a confirmation. The confirmation Message returns success (BOS_OK=0) or the following error codes:

• BOS_ERR_REMOTE_WRITE_TIMEOUT: Remote module did not respond.
• BOS_ERR_REMOTE_WRITE_MEM_FULL: No memory to create a new BOS variable.
• BOS_ERR_REMOTE_WRITE_INDEX: BOS variable index (address) is out of range.
• BOS_ERR_LOCAL_FORMAT_UPDATED: Remote BOS variable format does not match the requested one and thus was updated to match the request.
• BOS_ERR_REMOTE_WRITE_ADDRESS: Remote address is not a valid Flash or RAM location.
• BOS_ERR_REMOTE_WRITE_FLASH: Writing to a remote Flash location failed because the Flash page has not been erased

Note: In order to write to an MCU Flash address, the address must contain 0xFFFFFFFF or the entire page (1024 bytes) must be erased beforehand. If you are aware of the consequences of this and still want to force erasing the page if needed, use the WriteRemoteForce() API.