MEGA65 SD Detect Patch

 MEGA65 PCB REV 3, what can go wrong? The board has been working for some while, no commentary back that something is bad. Yet there is a real PCB Bug!

The internal large SD card socket case is not connected to a common GND. This as result makes the Card Detect function fail. So as SD detect was not yet tested the error got unnoticed.

How to Fix?

Option 1:

We need to scratch the solder mask off a bit, and then apply some solder to connect the SD Case to the GND plane.

Options 2, 3:

Options 2 and 3 do not need scratching the PCB they use short wire instead. Either wire 1 or 2 can be used, they do the same task.

VIO GPIO Test IP Core and Design

A simple and frequent task, how to set and read some random FPGA pin for test purposes? Sure this can be done over JTAG. Even the free JTAG BUZZ can do this. Well if you manage to get it up and running of course. My own ToolZ can readout in standard version, and theoretically could force pin state too, but well this function is currently not exposed. So there is an option to create a VIO core and connect it to the pin(s) of interest. This is always doable and works, but you are pretty much bound to make a new project every time and need to recompile new bitstream what takes its time.

OK amazingly JTAG BUZZ worked on brief testing, it allows single pin monitoring and continuity testing. There seems to be no function to set a single pin to static value.

But we wanted something for FPGA, the idea is that we can create a ready made bitstreams that implement some sort of generic VIO to GPIO gateway that connects at once to all available FPGA IO pins. Done, the IP Core includes about 10 lines of significant source code total.

Startup provides the FPGA internal free running clock so we do not depend on any external clocks being present. VIO_GPIO provides read-back of all connected IO pin simultaneously, selecting one pin by its index. The selected pin can be made output and its value can be forced to 0 or 1. At the same time this one pin is read back, and also connected to frequency meter IP Core. So if there are external clocks connected to the FPGA then we can measure their frequency (using internal clock a reference). 

Does it work? First try out and indeed all works as intended!

Here out1 is value to be written to the indexed pin, out2 is direction control (1 is output), out0 is pin index. The frequency meter also works, if we change the indexed pin output with mouse very quickly, then the frequency meter can show 1 Hz of detected frequency.

This design would work on all Xilinx 7 series FPGA and SoC or newer devices. Pretty much anything that can be programmed with Vivado can be used.

The first design was created for Zynq 7014 CLG484 package, it would without modifications also work for CLG400 package. For 7020 the same design should be one time recompiled.

For the XDC file I used the boundary scan order for the pins, so it is possible to look up the PAD number from Xilinx BSDL file, and convert to the "index" in the design. It is also possible to get the index from the XDC file. If we use package different from that in the original design then only the BSDL flow works to determine the ball-index mapping.

Scriptable UART/I2C Terminal

The need for this tool did come from the test requirement for the CR00040 I2C module, there are four I2C devices onboard and all of them should be checked during factory testing.

A simple test terminal application was used as a starting point, the edit box for the transmit string was changed to a memo to enter "test script". All lines from the memo are sent to the serial port, one line at a time. Two special cases added, when the first char on line is "=" then UART is read and compared to a string with display output on mismatch. On mismatch global RESULT variable is set to false. First char "!" is interpreted as a request for a timed delay in milliseconds.

Adding and testing those new features did take about half a day. While most of the time was spent troubleshooting a really silly bug (wrong string length on transmit).

This is an example output of the scripting terminal. All four I2C devices on CR00040 are tested. The CO2 sensor factory test is initiated, and the result is read back after 10 seconds delay needed by the sensor.

After starting the test a result will be displayed depending on the results of the read string comparisons, if all matched, then OKAY is displayed (or FAILED if at least one comparison failed).

Please note that while this tool was developed for I2C testing using the UHSA USB-I2C adapter, the tool could be used for more generic UART testing. It basically sends and receives UART strings having zero knowledge about I2C coded in.

While I2C is so common interface, yet every time we need to talk to some new I2C gadget, we have to spend some time to get something working. There are USB I2C dongles available that can do generic I2C transactions, but well none on my desk. So when I received this multisensor module, CR00040:

I instantly had a problem with how to test the sensors? What about making my own USB-I2C gadget? I decided to utilize an existing project that provided I2C access over UHSA protocol, the FPGA and NIOS softcore CPU code for this was there, it was developed for another sensor evaluation platform. So to adapt it I only had to change two PIN locations in Quartus. The most work was to trace the SCL, and SDA from the sensor module via PMOD-to-CRUVI adapter back to the MAX10 pins on the MAX1000 FPGA board. Well in any case the "fix" was done within less than 15 minutes. Does it work also? UHSA is ASCII based protocol so it is possible to "talk" using a keyboard and regular UART terminal. Unfortunately, there is little documentation on the UHSA so I had to look into some python code and the NIOS C sources also.

There are four I2C devices on CR00040, so trying them out one by one:

sending: <a6kfak<a7k..m..m..m..m..m..M>

response: 000801f12f7e632

from the response the three 0's are 3 ACK's from the I2C EEPROM, then come 6 bytes of EUI-48 Identifier code from address offset 0xFA. Yes, the EEPROM 24AA025E48 from Microchip is responding, so at least our I2C bus works!

sending: <bak0fk<bbk..M>

response: 000b1

now we see also 3 ACK's followed with WHOAMI response from the LPS22HB pressure sensor from ST.

sending: <72k91k<73k..m..M>

response: 00061e4

this is the correct response of DevID and REVision bytes from Ambient Light Sensor TSL25403M from AMS.

sending: <c4k36k82k<c5k..m..m..m..m..m..m..m..m..M>
response: 0000f5e7b89f07c23bf19a

and YES the CO2 sensor SCD40 from Sensiron is also responding with its unique serial number.

This is pretty good, time spent 15 minutes creating a generic USB I2C dongle for the CRUVI platform, and then well I spent a little more than an hour creating the UHSA strings to talk to the devices.

This is how the setup looks like on my desk:

I am using MAX1000 as a generic USB to PMOD adapter, then there is PMOD to CRUVI adapter (CR00025: pure passive, only connectors) and finally the CRUVI sensor module CR00040. Please note that there is SCD30 mounted on the MAX1000, it is not used in this setup.

The full source code of the Quartus project and the NIOS embedded code is open source, so if you have any Intel FPGA board that has a USB UART connection you can easily make your own USB I2C dongle and start working with any I2C devices from any application that can work with UART on the host PC. The NIOS subsystem includes only UART and GPIO, I2C is implemented as bit-bang to the GPIO. While in this example only I2C is supported, the same code can be adapted to support multiple interfaces over the same protocol, so you can talk to multiply I2C buses, or SPI, etc.

First CR00040 samples have been shipped to beta customers. CR00040 is compatible with CRUVI LS format so you can mount it directly on CRUVI motherboards like the VHDPlus Core MAX10.

With a PMOD adapter you can use it as if it would be a PMOD this adds more use cases. Also, CR00040 provides additional pin header holes to solder in pin headers, in that case, you can use fly cable, or insert the CR00040 into a solderless breadboard.

CR00040 will be soon available from Trenz Electronic and Arrow.

Repairing HyperLynx files

 We are using Altium designer to write out HYP files for HyperLynx. But some of our projects do not load in HyperLynx giving fatal errors on file loading.

Checking out Mentor(Siemens) support website, does not seem like I can enter my case problem there.

But let us see maybe we can see something in the file? The error at file load did give a line number in the source file, so looking at that place:

{NET=NetC147_2
  (PIN X=10.301860 Y=6.320791 R=L12.1 P=90)
  (PIN X=10.402907 Y=6.399201 R=C147.2 P=79)
  {POLYGON T=COPPER L="L 20 S" ID=24813 X=10.4702818 Y=6.3025418
    (LINE X=10.4642274 Y=6.2964874)
  }
  {POLYGON T=COPPER L="L 20 S" ID=24814 X=10.4522364 Y=6.3116777
  }

This is a snippet with good polygon and BAD polygon. It seems that Altium exports for some weird reason sometimes "empty" polygons with no primitives. Deleting those empty polygons, and voila my HYP file opens in HyperLynx.

Maybe I should report it as an Altium Designer bug?

Ah, where is the FIX? Well, our software designer wrote the utility that does remove those offending lines with less time I spent writing this blog entry. Needless to say, the utility worked. 

There is another bug with Altium HYP export: some PCB files with complex board outline will load wrong, they can look as if you have a triangle board outline. I do not know a real fix other than temporarily using a rectangular board outline for the HYP export process only.

UHSA UART High Speed ASCII

 UHSA stands for UART High Speed ASCII protocol. The protocol is designed to be very low level to be able to tunnel binary data to multiple streams. The encoding is ASCII so it can always be entered from a regular terminal program. The protocol is very simple and can be handled by microcontroller or FPGA code directly.

I really haven't had time to ever publish the protocol, but it is internally used in several products. One of them is TEI0010 a small sensor demo board. It is still available from Arrow online shop.

If you want to use this board for USB to I2C bridge then you need to change IO location for two pins:

You possibly also need to change the IO standard to 3.3V LVCMOS. 

Python source code is also included in the download archive. 

The design if not modified allows I2C and SPI access to all onboard sensors and peripherals.

#

# ADPD register access functions

#

def ADPD_write_reg(reg, value, serialport):

    serialport.reset_input_buffer()          

    cmd = "<c8K%0.2xK%0.2xK%0.2xK>" % (reg, (value >> 8), (value & 0xFF))

    serialport.write(bytearray(cmd,'utf8'))   

def ADPD_read_reg(reg, serialport):

    serialport.reset_input_buffer()          

    cmd = "<c8K%0.2xK<c9K..m..M>" % reg       

    serialport.write(bytearray(cmd,'utf8'))   

    s = serialport.read(4)

    return int(s, 16)

The above is UHSA encoded commands to read write a 16-bit register over the I2C bus.

  

Xilinx PUDC_B behavior

 Xilinx has lots of datasheets and documents describing their products. Still, it is sometimes not possible to know how Xilinx devices work. An example is the PUDC_B pin. This pin controls the pre-configuration pullups on I/O pads. When driven low then pullups are enabled. In 7 series this pin is located in a normal IO bank. So how do we disable the pre-configuration pull-ups? We need to drive PUDC_B to high (using a pullup resistor), in order to do that we need to supply I/O voltage to the bank that includes the PUDC_B pin. But when that power supply ramps up then initially PUDC_B would sample low and enable all pullups? So there must be a short time when pull-ups are enabled regardless of the PUDC_B pin?

So what it is? Does PUDC_B=high (resistive pull-up) really guarantee that pre-configuration pull-ups are disabled? Need to test. Need a suitable FPGA board first.

TE0723 Zynq Arduino board has PUDC_B pin accessible for measurements. Attaching DSO probes to spare I/O and PUDC and VCCIO of the bank.

And what we see? The spare I/O pin does indeed get pulled up, reaching 0.9 volts then dropping back to 0 when PUDC_B voltage reaches about 1 volt. Sure 0.9 volts is not yet logic high, but it is also not anymore valid logic 0 either. So the conclusion is that PUDC_B does not fully disable configuration pullups as the input reference is at about 1 volt causing the internal pullups to be enabled during power-up for short time.

Here at Xilinx forums some DSO screenshots!

GOWIN LittleBee development board

This small board (SKU TEC0117) for GOWIN FPGA is available from Trenz Electronics webshop. The JTAG programmer is on board - it is just a simple standard FT2223H MPSSE JTAG (empty FTDI EEPROM).

Pre programmed demo design is from RISC-V competition, it should show the following on the UART Terminal (115200, 8N1):

Note: depending on the production batch the boards may be unprogrammed from the factory. Note: you do not need GOWIN tools license to use the gowin programmer.

With empty FTDI EEPROM you need to select the second UART assigned to the board.

TIP: the GOWIN boards are delivered with empty FTDI EEPROM so they will enumerate as two UART's - it is OK to disable VCP loading for the channel A, then you only see one COM port assigned to the board. 

Select D2XX for Channel A and click program.