Categories

[ZeROSEro7] USB Keyboard detected !

This week, we have finished schematics and PCB. We finally ordered PCB of USB Sniffer, Spy Talk and Stealth Drop devices. I also worked on the USB Keyboard and the SD card.

USB Keyboard

I created a macro to change usbDbgPrintf by rtt_printf. Therefor, all debug functions are usable on the RTT connection.
I listened M. Tardieu advice and I tried to use the USB_FS (OTG1) instead the USB_HS (OTG2). And it’s worked ! The card detects the keyboard and generates interrupt. It’s even possible to print the key pressed on the keyboard thank to the HID USB.
The next step will be sending keyboard descriptors to the computer to be a man in the middle device.

SD card

I started to work on the SD card. I just got back an example from ChibiOS to read and write SD card by the RTT connection.
The software is able to detect the SD card and report information about it but the read command fails.

After Christmas Holiday

I will continue to work on these two issues.

[SpiROSE] Placing and routing in restrictive environment

Hello everybody !

Recently, I have worked on the PCB of the LED panels. It needs to be finished really soon in order to work on it shortly. For a brief recap, a LED panel has in its centre a 1920 LED matrix which is surrounded by 15 LED drivers, 5 of which are beneath the matrix and the remaining 10 above. Now we had to add the MOSFETs for the multiplexing as well as the clock buffers (2 buffers for SCLK, GCLK and LAT, for a total of 6 buffers). Since the drivers and the matrix had already been placed and routed, we tried to figure out what the optimal placing location for the MOSFETs, in order no to mess up the PCB too much.

Routing MOSFETS

Some MOSFETs with their multiplexing lines

Under each LED column, there is a plane for its corresponding multiplexing signal (the filled purple vertical plane). Since we have one MOSFET for each LED column, we chose to place the MOSFETs right where this plane ends, beneath the LED matrix. Yet, there is very little place: we indeed have vertical traces (the blue ones, layer 1) between all LEDS, which restrain the MOSFET place. With Unidan, I did run placing and routing tests to determine whether placing MOSFETs vertically or horizontally would make the routing more convenient. It appeared that the horizontal one gave best results, so I placed then routed this pattern. The MOSFET area is filled with a thin 4V plane.

Routing everything

Lower part of the LED panel, showing some MOSFETs, 2 LED drivers and 1 clock buffer (blue=top, red=bottom)

After that the struggle began, welcome to the trace jungle. Between the 5 bottom drivers are now placed 6 clock buffers, all aligned in a tiny place. The challenge was to route the output signals of the clock buffers up to the 10 upper drivers as well as routing the signals that will be transmitted from the rotary motherboard. The big issue is that we should only use 2 layers to do so, ie route all buffer/upper-driver, buffer/lower-driver, driver/matrix, MOSFET/MOSFET and MOSFET/multiplexing connections in the 2 external layers, since the 2 inner layers are used for Vcc and ground. I tried not to use the inner layers at all, but it was not entirely possible, so instead, I tried to minimize the length and the number of traces that occupied the aforementioned layers. By the way, using many custom colours for the different nets/traces/planes really helped a lot.

I have almost finished routing all nets, some still require a consequent length in inner layers and thus need to be improved. But is is not over, we still need to add the MOSFETs drivers as well as the board-to-board connector. This task is now our priority and will be carried out in the beginning of the upcoming week.

[ZeROSEro7] Host USB still get no descriptor…

This week, as last week, I worked on schematics and USB Keyboard.

Schematics and PCB

We almost finished schematics ! The second review on the USB Sniffer and the Stealth Drop was valid and few details have to be updated on the Spy Talk. PCB will be updated very soon.

USB Keyboard

I continued to work on the USB Keyboard issue. I updated the Makefile to compile with the ChibiOS_Contrib to use hal_usbh.h library.

In this file, there are some interesting typedefs:

  • USBHDriver
  • usbh_status
  • usbh_device
  • usbh_port
  • usbh_ep

…and some interesting functions:

  • usbhStart(USBHDriver *usbh);
  • usbhMainLoop(USBHDriver *usbh);
  • usbhDevicePrintInfo(usbh_device_t *dev);
  • usbhDevicePrintConfiguration(const uint8_t *descriptor, uint16_t rem);

I also found a very nice post on the ChibiOS forum which explain USB Host stack and driver for STM32. The contributor said he is still in development but he did it with some device like a Keyboard. It was 2 years ago, but I found some //TODO comment in the last ChibiOS version.

I got back files from HOST_USB example to integrate it in my project. I’m able to compile it and I added code in the main.c to use it. I configured OTG_HS (OTG2) pad correctly. I even verified the 5V tension on the USB_VBUS with a multi-meter and some device like a mouse where I can see LED turn on.

I used usbhDevicePrintInfo and usbhDevicePrintConfiguration on the USBHDriver USBHD2 to observe on the RTT connection all device information. Nevertheless, nothing happens and I only can see :

usbhDevicePrintInfo
----- Device info -----
Device descriptor:
USBSpec=0000, #configurations=0, langID0=0000
Class=00, Subclass=00, Protocol=00
VID=0000, PID=0000, Release=0000
----- End Device info -----

usbhDevicePrintConfiguration
----- Configuration info -----
Configuration descriptor:
Configuration 101, #IFs=104
----- End Configuration info -----

I’m still working on the step to get back USB Keyboard descriptor…

Next Week

Next week, I will command all PCB before Christmas and I will continue to work on the USB Keyboard.

[SpiROSE] LED Panel, end of place and route

Nothing really interesting for me this week, except place, route, place again, route again, etc.

The LED panel is pretty hard to route because of the constraints we have on it. Here are some stats about it:

  • There are 1920 LEDs, 15 drivers, 4 buffers, and 2 multiplexers inside a panel.
  • The top of the panel must have placeholders of approx. 10x10mm regularly to fix it using brackets, these placeholders will also be used as wires for electrical power input.
  • There will be 5 micro-blocks (a micro-block is a vertical set of 8×48 LEDs, with two drivers on top, one on bottom)

For fun, I looked at the stats from XPedition Layout, and saw there are approximately 12000 vias.

I would never have done everything by hand, it would have been too much repetitive work to check manually after. Hopefully mentor gives some utilities to help us copying blocks, here are the main ones I tried.

Hierarchical design and Instantiation

There are two main ways to design a circuit : by describing it explicitly, using pages to separate functions when possible (and appropriate), or abstracting parts of the schematic by defining new symbols representing a whole function.

The last method comes when the schematic is starting to get so big that it becomes difficult to read the schematics all at once. It is kinda similar to functions in procedural programming languages like C/C++. Another big advantage is the capacity of the symbols to be used more than once, making it easy to reuse a whole block.

This is where hierarchical designs can come in our design: designing a symbol as a whole micro-block makes the schematic approximately 5x smaller, with a guarantee that the micro-blocks will be wired in the exact same way. Finally, instantiating 5 micro-blocks let me place 5 big “components” already wired inside the PCB, and not manually placing and routing the 384 LEDs of the micro-block individually 🙂

Unfortunately, this systems works fine if it is conceived hierarchically from the beginning. If already placed and routed a micro-block, and putting it inside a symbol broke the link between the schematic and the PCB, breaking my place/route I already made…

Clusters and Circuit reuse

Another way of doing it is by using clusters. Cluster (Type 152 as described in the mentor’s documentation) is a type (physically represented by an integer) you can add in a device property. It acts as a group function: put some parts into the same cluster and they will be recognized as ‘equivalent’ parts. Here is how I’ve done this (UB0 is the reference micro-block, already placed/routed, I want to duplicate it and name the duplicated version UB1):

  • Set every LED’s cluster property in UB0 to a different number quickly by selecting the LEDs only (be careful not selecting special symbols like intrapage connector, power symbol, etc.) and using the ‘place text’ in ‘Type 152 – Cluster’ mode with options ‘auto-increment’.
  • Same for all the other devices like IC, resistors, capacitors, etc.
  • At this point there should be one element inside each cluster.
  • Copy paste (including net names) the whole UB0 schematic, and without unselecting it, replace text ‘UB0*’ to ‘UB1*’ with option ‘selected text only’ (I suppose all the different nets start with ‘UB0’, adapt as needed)
  • The schematic is ready!

Now for PCB:

  • Package, forward annotate.
  • Select (in select mode) UB0 parts, nets, vias, etc.
  • Now you have two options: direct paste (using clipboard) or save the selected circuit for future reuse.
  • If you activate licence for ‘Circuit Reuse’, you can save it (inside the ‘Edit’ menu).
  • Otherwise, just right-click and ‘Copy’. From there you should have a pin map assigner window where you can adjust your paste settings (if it does not show, just hit ‘F2’).
  • Oce it’s done, you can paste, and it’s done!

The problem with this being that there is no verification of integrity between the micro-blocks (if you rip/shortcut a wire somewhere in the schematic on one micro-block, you may not be notified).

This is what I applied because it is easier to use when you already have an existing design.

 

Next week, the last part will be added and the bottom part of the panel will be routed, finally!

 

[ZeROSEro7] Understand USB Keyboard

This week, I worked on Schematics, PCB and USB Keyboard.

Schematics

We finished first schematic version of each device. I updated some details on schematics before to begin all PCB.
I also added a spreadsheet of the STM32Fxx pin functions. Finally, I added a file in the wiki about the power supply of each component.

USB Keyboard

I started to work on the USB Keyboard Issue. The goal is to plug a PC to an STM32 (Olimex OTG1 port) and to plug the same STM32 (Olimex OTG2 port) to a USB Keyboard. The PC has to detect a keyboard without to see the STM32 between both. The STM32 has to get all USB Keyboard interaction as descriptors and interrupt to send it to the PC.

The first step would be to get USB Keyboard descriptors and show it on the RTT connection. However, I’m still working on this step.

I started to check the Olimex board connection to know jumper position and I updated the file board.h correctly.

USB protocol

I read documentations about the USB standard from the official website, some blogs as site OUAIBE de la BIDOUILLE and some forums. I got knowledge about how USB works. There are four types of communication : control, bulk, interrupt and isochronous. Note that Keyboard works with interrupt.

Each communication is constructed with different packet:

  • Token
Sync PID ADDR ENDP CRC5 EOP
8bits 2x4bits 7bits 4bits 5bits 3bits
  • Data
Sync PID DATA CRC16 EOP
8bits 2x4bits 1024bits 16bits 3bits
  • Handshake
Sync PID EOP
8bits 2x4bits 3bits
  • SOF (Start of Fram)
Sync PID FramNumber CRC5 EOP
8bits 2x4bits 5bits 3bits

Finally, there are four descriptors : devices, configuration, interface and endpoint descriptors. Each descriptors has field contain information about the device. The PID, VID, consumption, type of communication, etc.

USB on ChibiOS

My difficulties are to implement that on the STM32 and more specially with the OS we choose: ChibiOS.

I got back usbcfg from ChibiOS/testhal/STM32/STM32F4xx/USB_CDC_IAD/
This example uses two SerialUSBDriver SDU1 and SDU2 but not as a host.

I found another example at ChibiOS/community/testhal/STM32/STM32F4xx/USB_HOST/ which logically implement what we need. Nevertheless, the code is very hard to understand and is not possible to compile it. I try to debug the Makefile, but there are too many errors. I will continue to read ChibiOS documentation, code and forum to find a solution.

Next week

Next week, I will finished the spy talk PCB and continue to work on the USB Keyboard Issue.

[Little Brosers] Tree best reasons to start working on our C library

Guess what, I spent less time finding this posts’s title joke than last week. I’m getting good at it !

 

Reason one: No-More-Windows

Let’s just say that designing our PCB using Windows 10 on my MacBook Pro (late 2011) was not the best time effective part of ROSE. More seriously, our PCB’s design is now over. I spent some time this week tweaking last details: adding the VIAs all over the board and designing the antenna to SoC track adapting its impedance to get the most out of our tiny little baby 2.4GHz antenna.

Oh and, I forgot to mention the number one killer feature of this board : There will be the following text engraved in it: “Little Brosers ROSE 2018”. Wow. So fancy. Much professional.

Reason two: Winter is coming, the end of ROSE too

My dear fellows know as much as me how reassuring the countdown of this blog’s welcome page is. Or is it?

Regarding our project, we were building tiny parts of the project until now and some start to interact. (mostly Android and nrf52 bluetooth stack for now)

Our merkle tree implementation and the “diff-like” algorithm written in python by Guillaume are functional but need to be translated to some more optimized C code. This is what I started to do this week and what will fill the next ones.

There is some big issues about how we will allocate the memory for the merkle tree and how we will link it to the messages stored in the external flash. For now, we need to validate the diff-like algorithm in order to test it with the bluetooth stack.Thus, we will simply dynamically allocate the merkle tree. This is still a big chunk of work to do. Of course we will switch to a static allocation later in the project.

Reason tree: Credibility

I just needed three elements to make my joke.

See you next week !

Antony Lopez

[Little Brosers] Grounded in a tear drop shape

Ok so… Apart from spending 10 minutes to find a joke for this post’s title, I have well progressed on my Little Brosers tasks.

 

As I said in my previous post, this week as been all about PCBs. First some practice on the PCB design software and those 3 last days were dedicated to the drops’s schematic and PCB.

I’m happy to present you the very first version of our drop’s PCB :

 

To be honest, this is not fully ready yet. On tomorrow class I’ll improve the ground plan exclusion to shape it as a “U” letter.

Also I have to add some fixation holes and two targets for the component placing machine.

The round shape is mostly aesthetic. Since our product is called a “dead drop”, it seemed logical to make round.  It also reduces the size of the PCB since our biggest component is the round shaped battery holder. You can’t see it on the preview image but it is basically the same size than the PCB.

 

Cheers

Antony Lopez

[ZeROSEro7] Schematics

This week, I worked essentially on the USB Sniffer schematics and Spy Talk schematics.

LoRa SX1276

first day of the week, I continued to work on the SX1276. The purpose was to write an SPI interface between the microprocessor (nRF52832) and the LoRa module (SX1276). The difficulty is to well understand the microprocessor SDK (Nordic) and the LoRa SDK (icube) to merge each SPI interface.

We finally choose Enguerrand to manage this issue because of his great knowledge about Nordic and icube SDK. In addition, it was an emergency to start schematics, what I did.

Schematics

I got back Vincent’s work about USB Sniffer and continued the schematics on the XpeditionPCB software. I finished the first schematic version of this device. We got Mr. Polti A. feedback about it and I’m working to fix errors and update the schematics before start the PCB. I also started the Spy Talk schematics and almost finished the first version.

Next week

Next week, I will finish schematics of USB Sniffer and Spy Talk and start one PCB. We also received two USB OTG cables to plug a keyboard on the Olimex card. So I would like to begin working on the issue about reading keyboard action on the Olimex (STM32).

[Little Brosers] Stepping into the PCB’s design

Hello every one!

 

Ok, first things first : yes, my week in Madrid was great. Thanks for asking.

You need to see the Royal Palace if you ever go there, it’s beautiful. Seriously.

Let’s get back to our dear dead drops. I had no chance to publish any post last week but still, there is always something happening in the ROSE’s projects!

 

Updates on PSSC

We began this week with a meeting about PSSCs. To be honest, some of our early PSSC were late on schedule and others had not much time left before its deadline. Thus, the first days of the week were dedicated to put the finished ones in “Wait for validation” state and actually finish the others. We had a code review session as well as an android app test among the team’s member’s phones. The goal was to make sure the ongoing notification (the ones you can’t dismiss by swiping) generated by our app could not be dismissed on any of our phones.

We now wait for the ROSES’s guru’s validation.

 

Lucky me!

Ok, so this week I wanted to start our PCB. The thing is… there is not su much to wire, and that’s great!

 

Indeed, our drops will only contain a battery holder, a flash memory, a JTAG connector, a SoC , a quartz and some passive components. We don’t even need to bother about the battery recharging system because… we don’t need one. Remember! Our goal is to be able to hide our Drops in a hard to reach stash, we don’t care about recharging the battery.

Moreover, our dear Nordic engineers have put into their info center a typical NRF52832 schematic for us. I started from it to design our PCB.

Also, by default I chose the DC/DC power mode for the SoC. We’ll discuss it in our next group meeting, but it is very likely the power mode we will use considering its lower consumption compared to LDO power mode.

About our flash memory, we made the simple choice to take the same than the previous Dead Drops-like project (ROSE 2014). Of course, the idea is not to copy their work but reading theirs posts about this particular flash and their PCB helped me determine how we will wire it for our NRF52. In their logbook posts they also explained the few trubles they had with this flash memory. It’s a work we will not have to waist time on. Thanks’ fellows!

 

I guess that is all for this week.

 

See you next week!

 

Antony Lopez

SpiROSE: LEDs place and route

My week was dedicated to do the placement tests for the LED PCBs. The schematic for one ‘driver column’ (meaning the number of columns driven by a set of drivers to make a repeatable set) have been done using 3 drivers per ‘driver column’. The placement is:

  • 2 drivers on the top of the circuit, with a ground plane under
  • 3 ‘micro-planes’ of LEDs (a micro-plane is 8*16 LEDs in 8-multiplexing, with column multiplexing)
  • 1 driver on the bottom of the circuit, with a ground plane under

There have been multiple trials for the place and route, the pictures retrace the big steps.

This is the last version on the sunday morning.

Part of a driver being routed.

LEDs main view.

Schematic of 2/3rd of one ‘micro-column’

Details on the routing of the LEDs.

 

The components are all in the top layer, so that we can put two PCBs back to back without any problem (with an isolation layer between the two to avoid short-circuits).

The place and route step of the LEDs PCB is nearly finished, it should be done before the end of the week.