Skip navigation
1 2 3 Previous Next

Jan Cumps's Blog

104 posts

I'm trying out basic CAN communication on a Hercules microcontroller.

In this third blog I'll design driver PCBs.

The third part reviews the KiCAD PCB layout.

 

Two Layer PCB

 

I could have used a single layer PCB but there's no price difference with two layer boards.

The bottom side is dedicated to the power rail and ground. The top for the digital and analog signals.

 

Let's start with the bottom layer. Because the 3V3 isn't used a lot but crosses the whole board, I decided to route that first.

All the rest of the board area is ground. I added keepout areas on the two trough-hole connectors.

 

 

I've used the datasheet of the TCAN332D for the layout guidance.

These are the things I've taken over from the advice:

  • Transient Protection on CANH and CANL: ... These devices must be placed as close to the connector as possible
  • Decoupling Capacitors on VCC: Bypass and bulk capacitors must be placed as close as possible to the supply pins of transceiver
  • Ground and power connections: Use at least two vias for VCC and ground connections of bypass capacitors and protection devices to minimize trace and via inductance
  • Filtering noise on digital inputs and outputs: To filter noise on the digital I/O lines, a capacitor may be used close to the input side of the I/O

 

I didn't do anything specific for this one:

  • Because ESD and EFT transients have a wide frequency bandwidth from approximately 3 MHz to 3 GHz, high frequency layout techniques must be applied during PCB design.

I tried to keep all signals short and direct and provided a decent plane on the back. Only one signal goes trough a via (unfortunately in the transient protection circuit - maybe the worst one of the whole set?)

 

Layout

 

This wasn't a difficult exercise. The whole circuit is symmetrical and the components almost call for a particular position on the board.

You can see on the digital side on the board that there's nothing complex there.

 

The components on the left are the digital circuitry.

The bulky copper below U1 are the two power planes.

I've provided enough vias to get a good connection with the bottom planes.

 

The output circuit and protection are also symmetrical.

 

Here you can see that I used two vias to route the signal between R5 and C6.

Because this is a part of transient protection, it's best to have a short path .

I could have taken the proper time to rethink the position of a few components.

Putting D1 to the left of the output passives would have been one of the options.

 

 

The boards are ordered yesterday evening.

I've got a message from OSHPark that I got an upgrade to the Super Swift service and that the fab will make them within 5 business days.

 

The KiCAD project is attached to this blog.

 

Optional Components and Line Termination

 

The whole output protection part is optional. I do not intend to populate C5, C7 and D1 for this project.

These boards will not end up in a car. It will just be two of these talking together in the safe lab.

 

I don't need pull-up resistor R3 because the weak pull-up in the CAN driver together with the active pull that I will configure in my microcontroller should do.

I'll probe the signals once the circuit is built. If there's a sign of a weak digital signal, I'll try some pull-up values.

 

I will populate the CAN Bus termination components because both devices are end points and for signal integrity, both ends need to be terminated with a 120R impedance.

There are two options. I can either use two 60R for R5 and R6 and populate C6, or I can use 120R for one of the two resistors and bridge the other one. In that case C6 should not be placed.

Both options close the line as per specs. The first one has better common noise filter behaviour.

 

Monitor the Signals with an Analyser

 

I have some good news for @self here. I'm selected for the Microchip CAN Bus Analyser Tool road test.

I used this blog series as driver for the participation (see How I Enroll for a RoadTest - Part 6: Case for CAN Analysis Tool).

So I will have to make that happen now . I think it will be a very welcome instrument. My current analyser can probe the digital side only and doesn't understand CAN traffic.

With the CAN Bus analyser I'll be able to see traffic, but also to inject traffic on the bus. Excited.

 

 

 

Road Test Blog
part 1: First trials
part 2: Inject CAN Messages
part 3: Analyzer as Test Tool
Related Blog
part 1: tryout
part 2: Communication between 2 Devices
part 3a: Design a Bus Driver PCB
part 3b: Design a Bus Driver PCB - Schematics and Custom Components
part 3c: Design a Bus Driver PCB - Layout

I'm trying out basic CAN communication on a Hercules microcontroller.

In this third blog I'll design driver PCBs.

The second part describes schematic and custom KiCAD parts.

 

Schematic

 

I've used two sources for my schematic. The datasheet of the TCAN332D and an article on the TI e2e forum.

These are the things I've taken over from the advice:

  • TXD input pin: If an open-drain host processor is used to drive the TXD pin of the device,
    an external pullup resistor between 1 kΩ and 10 kΩ must be used to help drive the recessive
    input state of the device (weak internal pullup resistor). (R3)
  • Digital inputs and outputs: To limit current of digital lines, serial resistors may be used. (R1 and R2)
  • Decoupling Capacitors on VCC: Bypass and bulk capacitors must be placed as close as possible to the supply
    pins of transceiver. (C2 and C3)
  • Filtering noise on digital inputs and outputs: To filter noise on the digital I/O lines, a capacitor may be used
    close to the input side of the I/O. (C1)
  • Transient Protection on CANH and CANL: Transient Voltage Suppression (TVS) and capacitors can be used
    for additional system level protection. These devices must be placed as close to the connector as possible.
    This prevents the transient energy and noise from penetrating into other nets on the board.  (D1, C5 and C7)
  • Bus Termination on CANH and CANL: Split termination where the termination is split into two resistors, (R5 and R6),
    with the center or split tap of the termination connected to ground through capacitor (C6).
    Split termination provides common mode filtering for the bus.
    When termination is placed on the board instead of directly on the bus,
    care must be taken to ensure the terminating node is not removed from the bus,
    as this causes signal integrity issues if the bus is not properly terminated on both ends

Custom Components

 

The CAN driver and CAN bus ESD protection diode aren't available as KiCAD components.

For the TCAN332D, I used KiPART to generate the component from a spreadsheet.

Here's the spreadsheet content:

 

TCAN332D
typepinnamesidehidden
input1TXD left
output4RXD left
pwr2GND bottom
analog6CANL right
analog7CANH right
pwr3VCC top
nc5NCbottomyes
nc8NCbottomyes

 

The command line to execute the KiPART transformation:

 

C:\Python27\Scripts\kipart.exe -w -s num -f TCAN332D.csv -o TCAN332D.lib

 

The result is a new KiCAD lib with the following part:

 

For the NXP PESD1CANPESD1CAN CAN bus ESD protection diode I used the KiCAD Library Editor to draw one myself.

I used one of the existing Series Schottky Diode components that came with KiCAD as the inspiration.

Creating parts in the Library Editor isn't fun. Just saying.

Here's the result.

 

The spreadsheet and both libraries are attached to this blog post.

 

Road Test Blog
part 1: First trials
part 2: Inject CAN Messages
part 3: Analyzer as Test Tool
Related Blog
part 1: tryout
part 2: Communication between 2 Devices
part 3a: Design a Bus Driver PCB
part 3b: Design a Bus Driver PCB - Schematics and Custom Components
part 3c: Design a Bus Driver PCB - Layout

I'm trying out basic CAN communication on a Hercules microcontroller.

In this third blog I'll design driver PCBs.

The first part checks the design rules from the datasheet.

 

 

Real CAN driver

 

In the previous post I was using a makeshift CAN bus. But CAN buses that comply with the standard require a differential bus driver.

I bought 2 TCAN332DTCAN332D driver ICs. I've selected those because they are simple and require only a few additional components (in fact, if you don't care about protection: none. But that's not OK in automotive settings).

The PCB I design will have place for all protection components listed in the datasheet. I can choose to populate them or not. As long as I don't build them into a car, I can leave them off.

The board will also have optional components for the case when the device is an end point of the bus and needs to properly close the line with the correct impedance.

 

Here's the layout guideline from the tech ref.

 

(message to Texas Instruments: This is the ugliest Layout Example drawing I've ever seen in a datasheet. Where's your aesthetic feeling?)

 

My device doesn't have Fault, Sleep and Shutdown pins. I chose the simplest one. The grey components don't apply.

 

From the data sheet:

I removed instructions for signals not available on the TCAN332D

13.1 Layout Guidelines

TCAN33x family of devices incorporates integrated IEC 61000-4-2 ESD protection. Should the system requires

additional protection against ESD, EFT or surge, additional external protection and filtering circuitry may be

needed.

 

In order for the PCB design to be successful, start with design of the protection and filtering circuitry. Because

ESD and EFT transients have a wide frequency bandwidth from approximately 3 MHz to 3 GHz, high frequency

layout techniques must be applied during PCB design.

Design the bus protection components in the direction of the signal path. Do not force the transient current to

divert from the signal path to reach the protection device. Below is a list of layout recommendations when

designing a CAN transceiver into an application.

 

• Transient Protection on CANH and CANL: Transient Voltage Suppression (TVS) and capacitors (D1, C5 and

C7 shown in Figure 40) can be used for additional system level protection. These devices must be placed as

close to the connector as possible. This prevents the transient energy and noise from penetrating into other

nets on the board.

 

• Bus Termination on CANH and CANL: Figure 40 shows split termination where the termination is split into two

resistors, R5 and R6, with the center or split tap of the termination connected to ground through capacitor C6.

Split termination provides common mode filtering for the bus. When termination is placed on the board

instead of directly on the bus, care must be taken to ensure the terminating node is not removed from the

bus, as this causes signal integrity issues if the bus is not properly terminated on both ends.

 

• Decoupling Capacitors on VCC: Bypass and bulk capacitors must be placed as close as possible to the supply

pins of transceiver (examples are C2 and C3).

 

• Ground and power connections: Use at least two vias for VCC and ground connections of bypass capacitors

and protection devices to minimize trace and via inductance.

 

• Digital inputs and outputs: To limit current of digital lines, serial resistors may be used. Examples are R1, R2,

R3 and R4.

 

• Filtering noise on digital inputs and outputs: To filter noise on the digital I/O lines, a capacitor may be used

close to the input side of the I/O as shown by C1, C8 and C4.

 

• TXD input pin: If an open-drain host processor is used to drive the TXD pin of the device, an external pullup

resistor between 1 kΩ and 10 kΩ must be used to help drive the recessive input state of the device (weak

internal pullup resistor)

 

For the termination, I can use symmetric or simple:

 

I'll provide footprints for both options on the PCB. All in all, this will be an easy design.

I selected SOIC ICs, but smaller footprints are available.

I've designed some PCBs with smaller ones in the past but they turned out hard to reproduce.

 

In the next blog I'll start creating the PCB. And I'll use my favourite KiCAD tool Kipart to generate the IC schematic symbol.

For the disclaimer inclined reader: I purchased the ICs. The shipping was free. I have a free shipping agreement with the supplier.

 

 

Road Test Blog
part 1: First trials
part 2: Inject CAN Messages
part 3: Analyzer as Test Tool
Related Blog
part 1: tryout
part 2: Communication between 2 Devices
part 3a: Design a Bus Driver PCB
part 3b: Design a Bus Driver PCB - Schematics and Custom Components
part 3c: Design a Bus Driver PCB - Layout

I'm trying out basic CAN communication on a Hercules microcontroller.

This second test is sending data between two controllers. I'm using interrupts for reading and writing this time.

It's not yet a complete CAN implementation. The physical CAN BUS components are missing.

 

 

 

Simplified CAN driver

 

CAN communication requires line drivers. The microcontrollers that I'm using have CAN peripherals but their pins are generic IO that operate on the logic 3.3V level.

I'm using a poor man's CAN driver that requires one resistor and two diodes. Check my 2014 blog TI Hercules LaunchPad -  test the CAN with a poor man's CAN driver.

 

 

In the next blog I'll start to design the physical layer. I have 2 driver ICs at hand, but no schematic or PCB yet.

 

I'm using two Hercules LaunchPads. The smallest of the family, a TMS570LS04 and the biggest, the TMS570LC43.

The code for both is the same. Both send packages of data to each other and write what they receive to memory.

I'm using CAN peripheral 1 on both, mailbox 1 for sending, 2 for receiving.

The pinouts to get at those signals is shown in the images below.

 

 

 

Firmware

 

I've set a baud rate of 500 kBit/s.

The message boxes, different than in the previous blog, use unique IDs.

The small LaunchPad sends with ID 2 and listens to ID 1.

The big LaunchPad the other way around.

Because they are on the same bus, they should each read each others data and ignore their own messages.

The high priority interrupt for CAN1 is enabled on both.

 

The C code is straightforward. A few buffers and assorted other things are declared.

 

#define D_COUNT  8

uint32 cnt=0, error =0, tx_done =0;
uint8 tx_data[D_COUNT][8] = {0};
uint8 rx_data[D_COUNT][8] = {0};
uint8 *tx_ptr = &tx_data[0][0];
uint8 *rx_ptr = &rx_data[0][0];
uint8 *dptr=0;

 

The main() function initialises CAN, enables interrupts and error handling.

 

    /* enable irq interrupt in Cortex R4 */
    _enable_interrupt_();

    /** - writing a random data in RAM - to transmit */
    dumpSomeData();

    /** - configuring CAN1 */
    canInit();

    /** - enabling error interrupts */
    canEnableErrorNotification(canREG1);

 

Then it goes on to write some random data. Reading doesn't happen in main(). It's done in the interrupt service routine.

the tx_done flag is set in the ISR too, when the controller calls the interrupt after transmission is completed.

 

    /** - starting transmission */
     for(cnt=0;cnt<d_count;cnt++)
    {
      canTransmit(canREG1, canMESSAGE_BOX1, tx_ptr); /* transmitting 8 different chunks 1 by 1 */
      while(tx_done == 0){};                 /* ... wait until transmit request is through        */
      tx_done=0;
      tx_ptr +=8;    /* next chunk ...*/
    }

 

Here is that service routine.

 

#pragma WEAK(canMessageNotification)
void canMessageNotification(canBASE_t *node, uint32 messageBox)  
{

    if((node==canREG1)&& (messageBox == canMESSAGE_BOX1)) // transmit box
    {
      tx_done=1; /* confirm transfer request */
    }


    if((node==canREG1)&& (messageBox == canMESSAGE_BOX2)) // receive box
    {
     while(!canIsRxMessageArrived(canREG1, canMESSAGE_BOX2));
     canGetData(canREG1, canMESSAGE_BOX2, rx_ptr); /* copy to RAM */
     rx_ptr +=8;
    }

}

 

The first part handles the write interrupt. The full reading functionality is performed in the second part.

 

This simple program does nothing more than sending a few chunks of random data to each other, but that's ok for now.

It's a proof that two separate CANs can talk over a wire. A good start for the design with real physical CAN bus drivers.

 

Here's a capture of traffic generated by this setup:

 

Road Test Blog
part 1: First trials
part 2: Inject CAN Messages
part 3: Analyzer as Test Tool
Related Blog
part 1: tryout
part 2: Communication between 2 Devices
part 3a: Design a Bus Driver PCB
part 3b: Design a Bus Driver PCB - Schematics and Custom Components
part 3c: Design a Bus Driver PCB - Layout

The element14 roadtests are a great way to learn new things. Whenever I see a test that interests me, I enroll.

Success is not guaranteed. I've been selected for some, not for others. In this series I'll explain how I decide to enroll or not.

I'll also show how I build my case, including some examples from my applications.

 

This is the technical part of my application for the Microchip CAN Bus Analyser Tool .

All technical content is here. The self promotion bit I've culled because I've gone deep and low this time.

 

Application: Microchip CAN Bus Analyser Tool

 

I'm building a CAN project for the element14 blog.

I can (sic) use the Microchip CAN Bus Analyser to analyse and to document the traffic flowing between devices on a CAN bus.

I think that the unique angle of my proposal is that I will not attach it to a car and check its bus, but on a device that is being built here on the community site.

 

 

The analyser will be used in combination with automotive grade electronics. I have CAN capable microcontrollers and purchased CAN driver ICs (not for this roadtest but for my blog).

I'm building a custom PCB for the CAB physical layer. Schematics and layout will be part of the blog series and the analyser can play a real life role as an instrument for bus design.

The design will also include the firmware that generates the traffic. Readers can follow from code to physical signals to the Microchip CAN Bus Analyser.

This approach may be different than other proposals for this roadtest that focus on its analysis powers on existing vehicles.

canwithdrivers.jpg

 

  • Here are the CAN relevant articles that I've posted on element14 in the past:

Probing your Hercules LaunchPad CAN bus Part 1

Probing your Hercules LaunchPad CAN bus Part 2

Probing your Hercules LaunchPad CAN bus Part 3

 

  • New blog series that I just started this September:

CAN communication with Hercules Safety Microcontroller - part 1: tryout

(in draft status): CAN communication with Hercules Safety Microcontroller - part 2: Communication between 2 Devices

 

  • youtube videos:

https://youtu.be/-UhyPw-yMNE

https://youtu.be/r4VENkA06sg

https://youtu.be/ecngpvJPF5c

https://youtu.be/u6-SpcYdfRA

https://youtu.be/lRHfRknXsNo

https://youtu.be/MyPms4tcES4

 

As you can expect, there's a load of self tapping on the chest following here and loads of self-promotion. I'm not going to let you read it

 

 

Related blog
How I Enroll for a RoadTest - Part 1: yes or no
How I Enroll for a RoadTest - Part 2: success and failure
How I Enroll for a RoadTest - Part 3: Help Me
How I Enroll for a RoadTest - Part 4: Case for Programmable Electronic Load
How I Enroll for a RoadTest - Part 5: Case for Educational Switch Mode Converter Lab
How I Enroll for a RoadTest - Part 6: Case for CAN Analysis Tool

I'm trying out basic CAN communication on a Hercules microcontroller.

This first test is to test an example project.

Four CAN modules send an 8 char message out to themselves (so that we don't need external hardware).

 

What's tested here is how to set up CAN and how to use interrupt read-back.

 

 

 

The CAN example

 

This is the training code that comes with the HALCoGen configuration tool for Hercules.

It uses the controller's internal loop back mechanism to send messages to itself without going external.

This is an inherent part of the safety features of this controller: the ability to verify its own peripherals.

We use it here as part of a demo. In the Hercules safety library, this function is used to validate that the module works and fails safely.

 

 

 

 

 

I'm using a Hercules TMS570LC43 LaunchPad. The controller has 4 DAC modules. I enable all.

Then I configure a message sender (1) and receiver (2) for each of the 4 CANs. The message ID for sender and receiver have to be the same (I use 1), otherwise traffic is ignored by the receiver.

Interrupts are enabled on the receivers.

The image shows CAN #2. The setup is the same for all 4.

The high interrupts for the 4 CAN modules have to be enabled in the VIM table.

I'm showing CAN 1 here. It's interrupt 16.

the other ones are on position 35, 45 and 113.

 

The Code

 

We use a sender buffer for each of the 4 modules that contains dummy values (not really. It's Jack Kilby Day so I've adapted the content).

 

#define D_COUNT  8

uint8 tx_data1[D_COUNT] = {'J','a','c','k',' ', ' ',' ',' '};
uint8 tx_data2[D_COUNT] = {'K', 'i', 'l', 'b', 'y', ' ', ' ', ' '};
uint8 tx_data3[D_COUNT] = {'D', 'a', 'y', ' ', ' ', ' ', ' ', ' '};
uint8 tx_data4[D_COUNT] = {31,32,33,34,35,36,37,38};

 

The receive buffers are empty. At the end of the program they should get the same values as the send buffers.

 

uint8 rx_data1[D_COUNT] = {0};
uint8 rx_data2[D_COUNT] = {0};
uint8 rx_data3[D_COUNT] = {0};
uint8 rx_data4[D_COUNT] = {0};

 

At init time, we set the loop-back mode of the 4 CAN modules so that all traffic internally flows from the output to it's own input.

 

    /** - configuring CAN1 MB1,Msg ID-1 to transmit and CAN2 MB1 to receive */
    canInit();
    canEnableloopback(canREG1, Internal_Lbk);
    canEnableloopback(canREG2, Internal_Lbk);
    canEnableloopback(canREG3, Internal_Lbk);
    canEnableloopback(canREG4, Internal_Lbk);

 

The only thing the code will do is send the 4 messages. You will not find read functions here. That happens in the interrupt service handler.

 

    canTransmit(canREG1, canMESSAGE_BOX1, (const uint8 *) &tx_data1[0]);
    canTransmit(canREG2, canMESSAGE_BOX1, (const uint8 *) &tx_data2[0]);
    canTransmit(canREG3, canMESSAGE_BOX1, (const uint8 *) &tx_data3[0]);
    canTransmit(canREG4, canMESSAGE_BOX1, (const uint8 *) &tx_data4[0]);

 

The ISR receives the info and fills the receive buffers.

 

void canMessageNotification(canBASE_t *node, uint32 messageBox)  
{
    if(node==canREG1)
    {
        canGetData(canREG1, canMESSAGE_BOX2, (uint8 * )&rx_data1[0]); /* copy to RAM */
    }
    if(node==canREG2)
    {
        canGetData(canREG2, canMESSAGE_BOX2, (uint8 * )&rx_data2[0]); /* copy to RAM */
    }
    if(node==canREG3)
    {
        canGetData(canREG3, canMESSAGE_BOX2, (uint8 * )&rx_data3[0]); /* copy to RAM */
    }
    if(node==canREG4)
    {
        canGetData(canREG4, canMESSAGE_BOX2, (uint8 * )&rx_data4[0]); /* copy to RAM */
    }
}

 

This is a little exercise that learns how to configure the CAN peripherals. At the end of the program, the content of the receive buffers should be identical to the transmit info.

 

 

My next exercise will be to send CAN messages physically from one microcontroller to another.

 

Project attached. Have a nice Jack Kilby Day!

 

 

Road Test Blog
part 1: First trials
part 2: Inject CAN Messages
part 3: Analyzer as Test Tool
Related Blog
part 1: tryout
part 2: Communication between 2 Devices
part 3a: Design a Bus Driver PCB
part 3b: Design a Bus Driver PCB - Schematics and Custom Components
part 3c: Design a Bus Driver PCB - Layout

The element14 roadtests are a great way to learn new things. Whenever I see a test that interests me, I enroll.

Success is not guaranteed. I've been selected for some, not for others. In this series I'll explain how I decide to enroll or not.

I'll also show how I build my case, including some examples from my applications.

 

This is the technical part of my application for the TI-PMLK Buck Experiment Board: TPS54160 & LM3475

All technical content is here. I haven't removed the part where I'm doing blatant self promotion, because I know no shame.

 

Application: TI-PMLK Buck Experiment Board: TPS54160 & LM3475

 

This Road Test is a very nice fit with the blog series I have here on element14 related to switched mode DC conversion.

I am verifying different converter topologies and technologies and document my findings here on the community.

Although my blogs usually aren't product reviews (they are explanations and experiments) I have the skill, tools and will to verify the educational value of the offer.

 

 

 

My plan is to validate how the educational documentation helps the (to-be) engineer to understand modern switch-mode converters. I would also explain how to validate the characteristics of the design, showing how a typical test setup can detect those characteristics.

I would not investigate the performance of the converter chips themselves. That's something I would do in a road test for that particular IC. The nature of this test looks-and-feels to be focused on showing the kit's educational value.

Here is a selection of switch mode converter blogs that I have posted here on element14:

 

 

GaN Point of Load converter 48V to 1V 50A - part 1: Design Overview
Checking Out GaN Half-Bridge Power Stage: Texas Instruments LMG5200 - Part 1: Preview
Checking Out GaN Half-Bridge Power Stage: Texas Instruments LMG5200 - Part 2: Dead Time Capture
GaN Half-Bridge Power Stage: TI LMG5200 - Part 3: Control Deadband with Hercules LaunchPad
On the TI E2E community: driving GaN with a simple PWM signal
XuLA2 FPGA - PWM with Dead Band in VHDL
The GaN BoosterPack Series: LMG5200 Evaluation Pack and Smart Instrument
Hercules LaunchPad and GaN FETs - Part 1: Control Big Power with a Flimsy Mouse Scroll Wheel
Hercules LaunchPad and GaN FETs - Part 2: Make a BoosterPack
Hercules LaunchPad and GaN FETs - Part 3a: BoosterPack Layout - Reference Design
Hercules LaunchPad and GaN FETs - Part 3b: BoosterPack Layout - my version
Hercules LaunchPad and GaN FETs - Side Note A: BoosterPack Layout - Custom KiCad Parts
Hercules LaunchPad and GaN FETs - Side Note B: Look at the PCB
Low Voltage Step-Down Converter TPS54A20 - First Check
Low Voltage Step-Down Converter TPS54A20 - Series Capacitor

 

 

 

I am also designing an electronic load here on the community, together with fellow member Peter Oakes (we're working on this since last December. Every documentation and all our conversations are public here on the site).

Programmable Electronic Load

This design - using a microcontroller and several ICs from the same supplier - is a natural match for validating the kit.

 

The photo's in the application are taken from the blogs on this community.

 

 

single base scope scan

 

Thanks for considering my application.

Jan.

 

 

Related blog
How I Enroll for a RoadTest - Part 1: yes or no
How I Enroll for a RoadTest - Part 2: success and failure
How I Enroll for a RoadTest - Part 3: Help Me
How I Enroll for a RoadTest - Part 4: Case for Programmable Electronic Load
How I Enroll for a RoadTest - Part 5: Case for Educational Switch Mode Converter Lab
How I Enroll for a RoadTest - Part 6: Case for CAN Analysis Tool

I'm designing a BoosterPack to evaluate GaN devices with the help of a microcontroller.

I've received PCBs from Seeed. Let's have a look ...

 

This is my first Seeed order (a kind element14 community member gave me a rebate coupon that I happily used).

Board specifications:

 

  • PCB Dimension - 10cm Max*10cm Max
  • Layer - 4
  • PCB Thickness - 1.6mm
  • PCB Qty. - 5
  • PCB Color - Green
  • Surface Finish - ENIG
  • Copper Weight - 1oz.
  • Panelized PCBs - 1
  • Expedited Option - NO

 

The price without shipment for this board is 65.12€. Shipping was 7.37€. The coupon got me 9.15€ off ($ 10). Totals to 63.97€

This design requires 2oZ copper layers. My budget can't carry the cost of such a board - so I will not be able to draw full current out of my design.

This is a compromise, one of the many I had to make. I tried to avoid compromises in the design, but did make them when ordering.

Getting a board that has enough copper on it will not require a design change. It's just ticking a different option when ordering and coughing up the monies.

I'd rather do that after I validated that I didn't make mistakes in the PCB layout.

Just like previous designs I did with OSHPark, the Seeed boards look very good at first inspection.

This design is 4 layers, so I have no mechanism to look at the two inner layers. The top and bottom layer look very nice, so that's a good sign.

 

In the images below, the artist renditions on the left side are generated by the Seeed portal.

The photos on the right side are the actual thing. Click on them to get a detailed view.

 

boardtop.pngfront_seeed_pcb.jpg
back_seeed_pcb.jpg

 

 

Populate Order

This is the first time I'll populate a two-sided board. I'll use hot air for the smd components.This is how I plan to approach it:

  1. solder the GaN IC and the inductor. These two have the pins under the device. I'll have to massively bombard them with heat to transfer the energy underneath where the solder paste is.
    I'll use the pre-heater that shabaz gave  me to get the whole board to a close-to-reflow temperature.
  2. then all the smd components on the bottom side. If they fll of later, that's not a big deal, because the are only few.
    I'll also use the pre-heater but on lower temperature, because its heat will be radiating on the inductor and GaN chip.
  3. Then I'll do the remaining top smd components.
    The pre-heater again on a temperature low enough to not desolder the bottom components.
  4. the trough-hole components by hand

 

It is my first time. I'd be happy to take your advice on the preferred order to solder the components.

The tools I have at hand:

  • hot air
  • soldering iron
  • pre-heater

 

edit: I've attached the waveform of one High input pulse as hi01.wfm.

If you have a Rigol DS1052E you can upload that to your scope and examine the ringing with cursors.

 

 

Related Blogs
Hercules LaunchPad and GaN FETs - Part 1: Control Big Power with a Flimsy Mouse Scroll Wheel
Hercules LaunchPad and GaN FETs - Part 2: Make a BoosterPack
Hercules LaunchPad and GaN FETs - Part 3a: BoosterPack Layout - Reference Design
Hercules LaunchPad and GaN FETs - Part 3b: BoosterPack Layout - my version
Hercules LaunchPad and GaN FETs - Side Note A: BoosterPack Layout - Custom KiCad Parts
Hercules LaunchPad and GaN FETs - Side Note B: Look at the PCB
Rotary Encoders - Part 1: Electronics
Checking Out GaN Half-Bridge Power Stage: Texas Instruments LMG5200 - Part 1: Preview
Rotary Encoders - Part 4: Capturing Input on a Texas Instruments Hercules LaunchPad with eQEP
Vintage Turntable repair: Can I fix a Perpetuum Ebner from 1958 - part 4 - Hercules LaunchPad Enhanced PWM try-out

I'm designing a BoosterPack to evaluate GaN devices with the help of a microcontroller.

This double post (a+b) documents the PCB layout, specific for significant currency and high switching frequency.

 

 

Custom Schematic Elements and Footprints Strategy

I rule and live by the law of laziness. I do as little as possible and try to simplify anything that pops up.

That's reflected in my 'custom element creation' strategy: whenever there's a schematic or footprint available, I use it.

Many EEs - and many policies in companies - prefer to create an own footprint for all items used in designs. Not me.

 

Still, in this limited design, I had to create custom items.

For the GaN device and the quadrature encoder there was nothing. I made both symbol and footprint.

For the power connectors and the inductor, I had symbols but no footprints, so I made those.

I've also made a custom footprint for the vias (2 sizes), to have them exactly the same as the TI reference design.

 

The complexity of this exercise was from easy to difficult.

Schematic symbols were all easy. We have low pin counts.

For the footprints, the vias and connectors were easy, the inductor medium, and the LMG5200 and encoder hard. More on that when I describe each item.

All symbols and footprints are available in the attached archive. Each section starts with the filename of the asset in that attachment.

 

LMG5200 GaN IC

symbol LMG5200.lib

footprint lmg5200.pretty.zip

 

 

There's no existing symbol or footprint for the LMG5200 GaN half-bridge.

I used Dave Vandenbout's KiPart script to generate that part (read: copy-paste datasheet info into a spreadsheet and generate symbol from that).

 

LMG5200
typepinnameside
pwr1VINtop
output2HBright
output3HSright
input4HIleft
input5LIleft
pwr6VCCtop
pwr7AGNDbottom
output8SWright
pwr9PGNDbottom

 

See this blog for more info and instructions: Create my first KiCad part with KiPart utility.

The result is the following symbol:

 

To create the footprint of this item, I used the Package Information section of the datasheet.

I used the footprint editor to redraw package, copper and solder mask. There's a little bit of calculations needed to convert all the info in the images to coordinates.

Because the copper pads should blend with the PCB flood filled areas, I've set the pad's footprint to "From parent footprint".

This to avoid that we get thermal reliefs. They are not appropriate for this component (in particular for pins 1, 8 and 9).

 

EVQ-VVD00203B Square SMD Encoder

symbol: rotary_encoders_jan.lib

footprint: Panasonic_Rotary_Encoders.pretty

 

This one also doesn't have footprint or schema symbol. I used the KiCad editor to create the schema. I didn't go fancy.

 

The footprint was tough. The device requires three mounting holes, one of them oval.

 

You set the shape of the drill in the pad preferences.

 

282841-2282841-2Terminal Block 2x1 5.08mm TH

footprint: BuchananTerminalBlocks.pretty

 

 

For this one, I only needed the footprint.

 

This one is straightforward. Nothing special.

 

XAL8080-472ME Inductor, Shielded, Composite, 4.7uH, 10.5A, 8.89 ohm, SMD

footprint: coilcraft_incuctors.pretty

 

 

 

 

 

Again, only the footprint was needed. Just a transform from datasheet measurements to the KiCad footprint editor coordinates.

 

VIAs

footprint: vias.pretty

 

There's not much to be said about these. I made them to stay as close as possible to TI's reference design.

I needed 12 and 38 mil vias for that. Even though KiCad has via footprints, these two values aren't available.

All designs are available in the attached archive. If you are a 3-D artist, I could use your help to create nice KiCad  3-D models of the footprints.

That would make the exercise complete.

 

Related Blogs
Hercules LaunchPad and GaN FETs - Part 1: Control Big Power with a Flimsy Mouse Scroll Wheel
Hercules LaunchPad and GaN FETs - Part 2: Make a BoosterPack
Hercules LaunchPad and GaN FETs - Part 3a: BoosterPack Layout - Reference Design
Hercules LaunchPad and GaN FETs - Part 3b: BoosterPack Layout - my version
Hercules LaunchPad and GaN FETs - Side Note A: BoosterPack Layout - Custom KiCad Parts
Hercules LaunchPad and GaN FETs - Side Note B: Look at the PCB
Rotary Encoders - Part 1: Electronics
Checking Out GaN Half-Bridge Power Stage: Texas Instruments LMG5200 - Part 1: Preview
Rotary Encoders - Part 4: Capturing Input on a Texas Instruments Hercules LaunchPad with eQEP
Vintage Turntable repair: Can I fix a Perpetuum Ebner from 1958 - part 4 - Hercules LaunchPad Enhanced PWM try-out

I'm designing a BoosterPack to evaluate GaN devices with the help of a microcontroller.

board top Seeed

This double post (a+b) documents the PCB layout, specific for significant currency and high switching frequency.

 

 

The Schematic

The EVM User Guide has the schematics for this board. I removed the discrete deadband generator and bias voltage provider.

The deadband generator is replaced by a connection to Hercules LaunchXLII PWM outputs. The bias will come from that same LaunchPad's 5V power.

refschemaannotated.jpg

Here's my version. No bias or deadband circuit.
I've added a quadrature encoder. This part, connected to the Hercules eQEP module, is optional.

 

 

 

The PCB

Except for the changes mentioned above, I tried to stay as close as possible to the TI reference design.

There are several reasons for that:

  • budget: the PCB and GaN devices are expensive. I don't want to have to redo the work (ballpark figure: I loose more than 250 € on PCB and BOM for 3 boards, if I screw up. If you want me to be a hero, then send monies please).
  • I don't have anything close to the proper lab equipment to validate all aspects of the circuit's behaviour.
  • My "high switching frequency, high current" PCB layout skills are mediocre at best.

 

I am a little bit shaken by the cost of a four layer board. If you include shipping, I have a slightly cheaper quote for 3 OSHPark PCBs than for 5 Seeed PCBs with ENIG finish - if you include shipping costs.

A $10 coupon that I kindly got from michaelwylie tipped the balance, so I ordered at Seeed.

 

Here is my layout. You can compare it with TI's reference design images in my previous post.

 

Board Top (copper, mask, silkscreen, forgot to show the drill holes - see the image in the intro section above for those )

White annotations are not part of the PCB design. I've added those on the blog image for clarity (and because jc2048 requested it ).

 

boardtop.png

 

Middle Top layer

 

 

Middle Bottom layer

 

 

 

Board Bottom + copper, mask, silkscreen and drills

 

boardbottom.png

 

I've attached the KiCAD design to this post.

(edit: updated to v 1.1, C30, P2, P3 wrong footprint)

 

In the next post, I'll review the custom schematic and footprint components that I've created for this design - and upload their libs.

 

Related Blogs
Hercules LaunchPad and GaN FETs - Part 1: Control Big Power with a Flimsy Mouse Scroll Wheel
Hercules LaunchPad and GaN FETs - Part 2: Make a BoosterPack
Hercules LaunchPad and GaN FETs - Part 3a: BoosterPack Layout - Reference Design
Hercules LaunchPad and GaN FETs - Part 3b: BoosterPack Layout - my version
Hercules LaunchPad and GaN FETs - Side Note A: BoosterPack Layout - Custom KiCad Parts
Hercules LaunchPad and GaN FETs - Side Note B: Look at the PCB
Rotary Encoders - Part 1: Electronics
Checking Out GaN Half-Bridge Power Stage: Texas Instruments LMG5200 - Part 1: Preview
Rotary Encoders - Part 4: Capturing Input on a Texas Instruments Hercules LaunchPad with eQEP
Vintage Turntable repair: Can I fix a Perpetuum Ebner from 1958 - part 4 - Hercules LaunchPad Enhanced PWM try-out

 

I'm designing a BoosterPack to evaluate GaN devices with the help of a microcontroller.            

This post documents the PCB layout, specific for significant currency and high switching frequency.

 

The GaN Evaluation BoosterPack - Computer Controlled version of the Reference Design

The GaN BoosterPack that I'm designing is a close brother to TI's LMG5200 reference design. The power electronics part is - deliberate - identical to the reference.

The purpose of the circuit is to have an evaluation tool where you can check GaN FET behaviour under varying conditions.

So I left all GaN power related parts as-is, and replaced the input control logic.

The reference design uses RC circuits to generate the required input signals. The user controls frequency and duty cycle of that input circuit by providing an external PWM signal.

Other parameters, such as the deadband and the duty cycle ratio between different driver signals are preset.  You can change them by modifying the discrete components on the reference design (read: desoldering and replacing SMD caps and/or resistors).

 

I'm modding the design so that it takes the deadband from an external source. In my case, that source is a Hercules LaunchPad that runs an SCPI interpreter and can be controlled by LabVIEW.

 

The Gerbers for the reference designs are available from TI's website. If you load all the Gerber files into KiCAD's Gerber viewer, here are the ones you have to activate to get a good look-and-feel of the design:

  • 1 midlayer 1  G1 (upper midlayer)
  • 2 bottom layer GBL
  • 6 drill layer GD1
  • 7 drill guideline GG1
  • 23 interpanel GP1 (lower midlayer)
  • 26 top layer GTL
  • 3 bottom overlay GBO
  • 27 top overlay GTO

 

{gallery} TI Reference Design

Upper Mid Layer

1 midlayer 1  G1 (upper midlayer)

2 bottom layer GBL

2 bottom layer GBL

interpanel GP1 (lower midlayer)

23 interpanel GP1 (lower midlayer)

top layer GTL

26 top layer GTL

drill layer GD1

6 drill layer GD1

drill guideline GG1

7 drill guideline GG1

bottom overlay GBO

3 bottom overlay GBO

top overlay GTO

27 top overlay GTO

Layer Stack Up

 

 

The Layout Application Note

TI has an elaborate  guide with 'Layout Considerations for LMG5200 GaN Power Stage'. This document contains theory and practice on how to layout 2 or 4 layer PCBs for this device.

This goes well together with the EVM kit that I'm copy-catting here. The PCB of the EVM is used as the practical realisation of the layout theories and guidelines.

That means that I have all that's needed for my work: explanation, a physical example (TI gave me an EVM) and the Gerber files. Over to KiCad and draw my own version...

 

 

 

In the next post I'll post the schematics and PCB layout - and the KiCAD sources.

(was planning to do that now, but I can't upload images to the blog since this afternoon...)

 

Related Blogs
Hercules LaunchPad and GaN FETs - Part 1: Control Big Power with a Flimsy Mouse Scroll Wheel
Hercules LaunchPad and GaN FETs - Part 2: Make a BoosterPack
Hercules LaunchPad and GaN FETs - Part 3a: BoosterPack Layout - Reference Design
Hercules LaunchPad and GaN FETs - Part 3b: BoosterPack Layout - my version
Hercules LaunchPad and GaN FETs - Side Note A: BoosterPack Layout - Custom KiCad Parts
Hercules LaunchPad and GaN FETs - Side Note B: Look at the PCB
Rotary Encoders - Part 1: Electronics
Checking Out GaN Half-Bridge Power Stage: Texas Instruments LMG5200 - Part 1: Preview
Rotary Encoders - Part 4: Capturing Input on a Texas Instruments Hercules LaunchPad with eQEP
Vintage Turntable repair: Can I fix a Perpetuum Ebner from 1958 - part 4 - Hercules LaunchPad Enhanced PWM try-out
For a hardware evaluation project I'm working on, I want to create a device that can be controlled via LabVIEW.
LabVIEW can talk to instruments using serial out of the box, and it knows how to talk Standard Commands for Programmable Instruments (SCPI).

 

 

In this blog I adapt the LabVIEW Virtual Instrument and the firmware to give direct access to the Hercules PWM Time base control registers.

You'll be able to independently set all 7 PWM modules that are available on the controller.

 

 

The FirmWare Support for Direct Register Access

I provided a SCPI command that can receive a numeric value from LabVIEW and write that to the correct PWM module.

Here's the pattern:

    {.pattern = "PWM#:TBCTL", .callback = SCPI_HerculesPwmTBCTL,},

 

The implementation is very simple. Just like in the previous blog, we'll retrieve the PWM module, and the register value, from the SCPI command we get from LabVIEW.

LabView will send something like this:

PWM2:TBCTL #H200

 

We'll have to derive from this string that the PWM register set we have to address is that of PWM module 2.

And we'll have to write 0x0200 into its TBCTL register.

 

I have refactored my code since the first blog, to separate the Hercules PWM details from the SCPI parser. And I've factored out some functionality that can be reused accross many functions.

The code to get the right PWM module has gotten its own function:

 

static scpi_result_t PwmGetModule(scpi_t *context, uint32_t *uModule) {
  int32_t numbers[1];

  // retrieve the PWM channel. Can be 1 - 7
  SCPI_CommandNumbers(context, numbers, 1, 1);
  if (! ((numbers[0] > 0) && (numbers[0] < 8) )) {
  // todo push error on stack if the PWM CHANNEL not between 1 and 7
  return SCPI_RES_ERR;
  } else {
  *uModule = numbers[0];
  return SCPI_RES_OK;
  }
}

 

And here's the code that parses ut the register value and sends all to the Hercules PWM side:

/**
 * Set PWM register TBCTL
 *
 * Return SCPI_RES_OK
 *
 */
static scpi_result_t SCPI_HerculesPwmTBCTL(scpi_t * context) {

    int32_t param1;
    uint32_t uModule;
    if (PwmGetModule(context, &uModule) == SCPI_RES_ERR) {
        return SCPI_RES_ERR;
    }

     /* read first parameter if present */
     if (!SCPI_ParamInt32(context, &param1, TRUE)) {
         return SCPI_RES_ERR;
     }
     pwmTBCTL(uModule, param1);

    return SCPI_RES_OK;
}

 

In that PWM part, I simply write the value to the relevant register of the correct module:

// array of the 7 PWM registers of the RM46
etpwmBASE_t *pwmRegs[7] ={etpwmREG1, etpwmREG2, etpwmREG3, etpwmREG4, etpwmREG5, etpwmREG6, etpwmREG7} ;

void pwmTBCTL(uint32_t uModule, uint16_t uValue) {
  pwmRegs[uModule-1] -> TBCTL = uValue;
}

 

TBCTL is a 16 bit register that drives the following PWM behaviour (and more, that I don't discuss here):

Bit 9 - 7 are the high speed clock divider bits. A few examples

0b111: /14

0b001: /2

0b000: /1

 

Bit 1 - 0 indicate the counter mode. We'll use these two in our example:

0b00: normal up count

0b11: freeze counter

 

That's why you'll see the following useful Hex codes on the LabVIEW display below:

PWM 1 MHz: 0

PWM 500 kHz: 80

PWM 125 kHz: 200

PWM of: 3

 

This register isn't the one where you will later define the exact frequencies. I'll provide additional SCPI functionality to talk to those.

But for the things we want to show here - that we can select to what module we talk, and can push data to a register - TBCTL  will do just fine.

 

The LabVIEW Design

This version of the LabVIEW panel has two user editable controls.

There's a dial that allows you to select PWM module 1 to 7.

 

When you run the LabVIEW process, it will talk to that PWM module of your Hercules LaunchPad.

 

The second control is an edit box where you can type the hexadecimal value of what you want to write to that PWM module's TBCTL  register.

For convenience, I've added a table with some useful values next to it.

Use this edit box together with your controller's technical reference manual.

The LabVIEW program here is a great tool for you to better learn your controller's PWM module.

You can type in any value you like (better base it on the instructions in the TRM ), and beam them directly into the register.

You can attach a scope and see the results.

 

Here's the very simple LabVIEW block diagram.

The string constant holds the following value:

PWM%u:TBCTL\s#H%s\n

 

That is sent into a Format Into String block, together with the values of the dial and the edit control.

At the output of the block, you'll get:

PWM2:TBCTL #H80\n

 

That is sent off to the Hercules LaunchPad over USB.

 

The results

Let's see how the outputs of PWM module 1 and 2 look lik when we send a few commands.

 

After sending 0x3 to both modules (both off):

 

After sending 0x80 to PWM 2 (500kHz):

 

After sending 0x0 to PWM 1 (1MHz):

 

 

It's easier to understand why 0x03 switches off the PWM signal and why the other magical HEX values do what they do if you know the layout of the register we're addressing. Here are the relevant bits explained.

Source:  http://www.ti.com/lit/pdf/spnu514

 

 

The source for LabVIEW and the Hercules CCS project are attached to this blog.

You can try this yourself.

 

 

Related Blog

Create a Programmable Instrument with SCPI - Part 1: Parser Library
Create a Programmable Instrument with SCPI - Part 2: Serial over USB
Create a Programmable Instrument with SCPI - Part 3: First Conversation *IDN?
Create a Programmable Instrument with SCPI - Part 4: Error Handling by Default
Create a Programmable Instrument with SCPI - Part 5: First Hardware Commands
Create a Programmable Instrument with SCPI - Part 6: LabVIEW Integration
Create a Programmable Instrument with SCPI - Part 7: Talk to Hardware Registers
For a hardware evaluation project I'm working on, I want to create a device that can be controlled via LabVIEW.
LabVIEW can talk to instruments using serial out of the box, and it knows how to talk Standard Commands for Programmable Instruments (SCPI).

 

 

In this blog I make a LabVIEW Virtual Instrument that turns PWM signals on and off.

 

 

LabVIEW Design

We'll create a LabVIEW control panel that can toggle PWM output of a Hercules microcontroller.

In the previous blogs we enabled our Hercules LaunchPad USB and made firmware that knows how to interpret SCPI.

Our LabVIEW program has to be able to connect to our USB port and send SCPI commands.

We'll use a toggle button to switch PWM on and off.

 

Requirements of the LabVIEW design:

  • connect to a COM port and talk serial
  • Send the right SCPI commands to the COM port, depending on the position of the toggle switch.

 

There's an example program in LabVIEW that gets us 70% of what we need: examples\Instrument IO\Serial\Simple Serial.vi.

That one can connect to our LaunchPad over USB and send the SCPI command *IDN? (we've used this program earlier on in our tests).

We can use the complete program - we just need to replace the constant string '*IDN?' with either PWM1:STATe ON or PWM1:STATe OFF depending on the state of our toggle switch.

 

That isn't hard. The first thing we do is place a boolean control on our canvas. I selected a switch that gives a good indication of On/Off. I named it PWM.

 

Then, in the Block Diagram,I added a Case block, and wired the switch to that.

I also added two constant string items, one containing PWM1:STATe ON,the other PWM1:STATe OFF.

I wired the two strings to the case statement as inputs. The output of the case statement is routed to where the original *IDN? data was flowing.

 

 

 

In the case block, for the False state, I routed the OFF input to the output. For the True state, I routed the ON input. And that's it.

To test the program, set the toggle in the desired position and run your LabVIEW program.

The PWM output will switch on or off based on that.

 

 

I've attached the LabVIEW project to this blog. The firmware for the Hercules LaunchPad is available in the previous one.

Give it a try!

 

Related Blog

Create a Programmable Instrument with SCPI - Part 1: Parser Library
Create a Programmable Instrument with SCPI - Part 2: Serial over USB
Create a Programmable Instrument with SCPI - Part 3: First Conversation *IDN?
Create a Programmable Instrument with SCPI - Part 4: Error Handling by Default
Create a Programmable Instrument with SCPI - Part 5: First Hardware Commands
Create a Programmable Instrument with SCPI - Part 6: LabVIEW Integration
Create a Programmable Instrument with SCPI - Part 7: Talk to Hardware Registers
For a hardware evaluation project I'm working on, I want to create a device that can be controlled via LabVIEW.
LabVIEW can talk to instruments using serial out of the box, and it knows how to talk Standard Commands for Programmable Instruments (SCPI).

 

scpi PWM On

 

In this blog I build the first hardware command to turn PWM signals on and off.

 

 

One Function Handles 7 PWM Modules

The first command isn't the easiest one. We'll build a function that can talk to any of 7 available PWM modules of the Hercules controller.

SCPI has a construct that allows you to provide a wildcard in the command. That wildcard can be replaced by a number when calling the command from LabVIEW.

 

    {.pattern = "PWM#:STATe", .callback = SCPI_HerculesPwmState,},

 

When you shoot a command where the # is substituded by a number  (i.e.: PWM1:STATe ON), the SCPI_HerculesPwmState() function gets called.

The substituted number is available in that function by calling the API SCPI_CommandNumbers().

With that number, I retrieve the correct PWM hardware register and switch the signal on or off.

 

PWM on off via USB

 

These are the SCPI test calls:

PWM1:STATe ON
PWM1:STATe OFF

 

This is the function that gets called. Don't worry about the magical numbers that are assigned to the PWM register. I'll improve the code while I design the firmware.

param1 holds true if you pass ON or 1 in SCPI command. false if you give OFF or 0.

 

// array of the 7 PWM registers of the Hercules RM46 controller
etpwmBASE_t *pwmRegs[7] ={etpwmREG1, etpwmREG2, etpwmREG3, etpwmREG4, etpwmREG5, etpwmREG6, etpwmREG7} ;

static scpi_result_t SCPI_HerculesPwmState(scpi_t * context) {

    int32_t numbers[1];
    scpi_bool_t param1;
    etpwmBASE_t *pwmReg = NULL;

    // retrieve the PWM channel. Can be 1 - 7
    SCPI_CommandNumbers(context, numbers, 1, 1);

    // todo error if the PWM CHANNEL not between 0 and 7.
    // code below will fail because we'll read invalid memory locations
    pwmReg = pwmRegs[numbers[0]-1];

     /* read first parameter if present */
     if (!SCPI_ParamBool(context, &param1, TRUE)) {
         return SCPI_RES_ERR;
     }
     if (param1) { // switch PWM on
         pwmReg -> TBCTL = ETPWM1_TBCTL_CONFIGVALUE;
     } else { // switch PWM off
         pwmReg -> TBCTL = 131;
     }

    return SCPI_RES_OK;
}

 

That substitution is a powerful construct. With little effort I can control multiple similar modules.

The SCPI library has all the logic that's needed to support this. I just have to use it properly.

Once more it didn't take a lot of code to build flexible functionality.

 

I've attached the CCS project to this blog.

Compile, load to your RM46 LaunchPad and connect with a serial terminal program using 9600, 8, 2, N

 

Put an oscilloscope probe on J11 16 and 18. You'll find two complementary 1MHz PWM signals.

Submit these commands in putty to switch them off and back on:

 

 

 

PWM1:STATe OFF
PWM1:STATe ON

 

In the next blog I'll attach a LabVIEW example that switches the signals.

 

Related Blog

Create a Programmable Instrument with SCPI - Part 1: Parser Library
Create a Programmable Instrument with SCPI - Part 2: Serial over USB
Create a Programmable Instrument with SCPI - Part 3: First Conversation *IDN?
Create a Programmable Instrument with SCPI - Part 4: Error Handling by Default
Create a Programmable Instrument with SCPI - Part 5: First Hardware Commands
Create a Programmable Instrument with SCPI - Part 6: LabVIEW Integration
Create a Programmable Instrument with SCPI - Part 7: Talk to Hardware Registers
For a hardware evaluation project I'm working on, I want to create a device that can be controlled via LabView.
LabView can talk to instruments using serial out of the box, and it knows how to talk Standard Commands for Programmable Instruments (SCPI).

 

 

In this blog I'm checking the excellent error handling of the SCPI library.

 

 

Error Handling Works by Default

The SCPI parser library that I use has out-of-box support for standard behaviour. One of the supported features is error handling.

If you send a bogus SCPI command or make a syntax error, this is registered by the library.

The error description is pushed on an error stack. The parser returns to its normal work.

As an instrument firmware designer, you can also push custom error situations to the error stack.

A possible use case is for a PWM generator where the user requests a frequency higher than the maximum.

 

You can check if errors occurred by sending the SCPI command:

SYST:ERR:COUN?

 

If errors happened, you get a number back. That's the count of errors on the stack.

e.g.:

5

 

Each error can be retrieved by firing:

SYST:ERR?

 

A possible return value (one of the default error messages from our parser lib):

-113,"Undefined header"

 

Each time you ask an error message, the error is popped off the stack and the error count decreases.

When you've retrieved the last message, you get the following reply when shooting a  SYST:ERR:COUN? :

0

 

If you check for an error message when the error stack is empty, (SYST:ERR?), you get:

0,"No error"

 

You get all this functionality by default and you can tap into it in your own firmware. Another worry taken out of your hands by this library.

Other standard constructs that are either fully supported, or give you an easy implementation hook are:

 

    { .pattern = "*CLS", .callback = SCPI_CoreCls,},
    { .pattern = "*ESE", .callback = SCPI_CoreEse,},
    { .pattern = "*ESE?", .callback = SCPI_CoreEseQ,},
    { .pattern = "*ESR?", .callback = SCPI_CoreEsrQ,},
    { .pattern = "*IDN?", .callback = SCPI_CoreIdnQ,},
    { .pattern = "*OPC", .callback = SCPI_CoreOpc,},
    { .pattern = "*OPC?", .callback = SCPI_CoreOpcQ,},
    { .pattern = "*RST", .callback = SCPI_CoreRst,},
    { .pattern = "*SRE", .callback = SCPI_CoreSre,},
    { .pattern = "*SRE?", .callback = SCPI_CoreSreQ,},
    { .pattern = "*STB?", .callback = SCPI_CoreStbQ,},
    { .pattern = "*TST?", .callback = SCPI_CoreTstQ,},
    { .pattern = "*WAI", .callback = SCPI_CoreWai,},

 

 

Test with PuTTY

 

When you want to test special conditions, it's often easier to use a terminal program than LabVIEW. You can just type away, and the results arrive in the parser lib immediately.

 

When I try to simulate a real test environment, I mock it with LabVIEW. But when I try to exercise a particular part of the library, or want to see how my firmware reacts on each single character (valid or invalid), plain old PuTTY is easier.

 

PuTTY is also easy to learn the SCPI parser lib. Set a breakpoint in the SCPI_Input() function and type *IDN?<enter> in PuTTY. Your code breaks at each character you type. You can step trough the logic that builds up the command string. You'll also see how the library recognises when it received a full command.

You can then step trough the execution of the code that implements that command.

If you do that a few times, you'll get a deep understanding of the library. It 'll help you to extend it in the right way.

 

Related Blog

Create a Programmable Instrument with SCPI - Part 1: Parser Library
Create a Programmable Instrument with SCPI - Part 2: Serial over USB
Create a Programmable Instrument with SCPI - Part 3: First Conversation *IDN?
Create a Programmable Instrument with SCPI - Part 4: Error Handling by Default
Create a Programmable Instrument with SCPI - Part 5: First Hardware Commands
Create a Programmable Instrument with SCPI - Part 6: LabVIEW Integration
Create a Programmable Instrument with SCPI - Part 7: Talk to Hardware Registers