• Troubleshooting the problem - part 2

    Stephen G • 02/15/2024 at 11:40 • 0 comments

    After realising that I'd mixed up the rows and columns of the matrix, I still wanted to verify that once that was fixed, then everything would work. This wasn't too hard to test - I just needed to put the matrix in a breadboard, and then connect that with jumpers to the socket on my PCB. For example, pin 1 on the matrix, which is the cathode for row 5, needs to be connected to pin 6 on the PCB socket, because that is the pin that controls column 5. And vice versa - pin 6 on the matrix needs to connect to pin 1 on the PCB socket. After connecting up the 8 pairs of pins in this manner, I turned on my test circuit again - and there was good and bad news.
    The good news was that I was indeed individually controlling the LEDs the way I expected. However the bad news was that I had once again missed a crucial detail in the datasheet. On the bottom left of page 8, it shows that the most significant bit of the register controls the DP line. I had connected the DP line to the right-most column of the matrix, meaning that when a wrote a byte to one of the MAX7219 registers, the bits were displayed out of order. The bits were displayed in the order 65432107, and everthing needed to move one column to the right. This could be corrected in software by shifting the bits around before writing them to the MAX7219, but given I already needed to do a new version of the PCB, I wanted to fix it properly.


    So I mapped out the jumper connections needed to get a 100% working display on my current PCB:
    MAX7219 SEG_DP pin -> currently connected to pin 5 of PCB socket -> this is row 8 -> swap to col 8 -> shift to col 1 -> pin 13 of matrix
    So a jumper goes from pin 5 of the PCB socket to pin 13 of the display.
    MAX7219 SEG_A pin -> currently connected to pin 9 of PCB socket -> this is row 1 -> swap to col 1 -> shift to col 2 -> pin 3 of matrix
    Jumper from pin 9 of socket to pin 3 of the matrix.
    SEG_B -> pin 14 -> row 2 -> col 2 -> col 3 -> pin 4
    etc.

    After rewiring the affected jumpers, the display started working perfectly.
    So the lesson here is - read the datasheet... and then read it again! And don't assume ANYTHING. I have a revision B board ready for fabrication now and will send it along with another board I'm working on.

  • Troubleshooting the problem - part 1

    Stephen G • 02/05/2024 at 05:35 • 0 comments

    It took me a while, but I've confirmed what went wrong in the design of the first version of the board. Hopefully someone finds the process interesting.

    The first thing I wanted to do was confirm that the SPI messages from the MCU were OK. Therefore, I connected up my logic analyzer and captured the trace below. As you can see, this is an incredibly useful (and cheap) debugging tool. I use one of the 24MHz 8-channel analyzers that go for something like $25 on AliExpress. This is connected up to PulseView, which has an SPI trace decoder plugin. Whilst doing this, I did check the timings of my SPI signals and found they were actually violating the datasheet requirements for setup and hold time. This wasn't a problem for the pre-built modules that I've been using, but I thought perhaps the batch of cheap MAX7219s I had bought were a little more fussy. So I adjusted the timings in my code, but this didn't make any difference. This is an important thing to be aware of though, especially with higher-speed transfers (SPI is considered slow).


    So this seemed to eliminate one option (although I never consider anything truly eliminated - just the probability is reduced). I didn't really have a way of validating the functionality of the MAX7219 chips, so I figured I'd double-check my schematic. In the process of going over this, I realised that when I was designing it, I had made a bit of a leap of logic that might not be justified. In the "datasheet" (generous, as it's just a single diagram) for the 1088AS led matrix, it shows clearly which pins are anodes (columns) and which ones are cathodes (rows). When I drew the schematic, I added the symbol for the MAX7219 and the pins are labelled SEG_A thru SEG_G and DIG_0 thru DIG_7. I figured that the "columns" of the matrix (running left to right) would be the same as digits of an 8-digit display (running left to right). However, this was actually an assumption. When I came back to it with a critical eye, I remembered that LED displays come in common-anode and common-cathode versions, so this needs verification. A quick look at the MAX7219 datasheet shows that DIG0-7 are "Eight-digit drive lines that sink current from the display common cathode". I had connected these to the anodes of the LEDs.
    The behaviour of the matrix now made sense - as the datasheet explains ... "The MAX7219 pulls
    the digit outputs to V+ when turned off.    " and "when a segment driver is turned off it is pulled to GND". This means that when I turned all the LEDs off, they would actually be turned on. (In contrast, MAX7221 sets both anode and cathode to high-Z when LEDs are off).
    But wait, wouldn't this mean that the display is completely inverse? Well, no. The way it drives 64 LEDs is to drive each digit in turn (scanning). If you do this quickly enough, the "persistence of vision" effect means that your eye perceives the light as constant (also, LEDs don't turn off instantly). So LEDs that are "on" are actually only on for a fraction of the time and off for the rest of the time. LEDs that are "off" are in fact off all of the time. If we invert the signals, "On" LEDs are still on for a fraction of the time, and appear on - not off. And "Off" LEDs will be on the whole time. So the whole display just appears to always be on - which is the behaviour I was seeing.

  • First batch of PCBs arrived (thanks PCBWay)

    Stephen G • 01/08/2024 at 10:42 • 0 comments

    My batch of PCBs arrived. This is my first time using PCBWay, so I was keen to see how they looked. I am quite happy with them and cannot identify any flaws visually (even after zooming in on a photo). I was convinced to try PCBWay because they contacted me offering to send a free batch of PCBs, so I took them up on the offer.

    I've soldered up a module but so far, things are not looking great - when I apply power, every LED lights up. I've already checked the connection on the PCB itself, so either:

    • MAX7219 is not working properly
    • PIC is not sending proper instructions, or timing of signals is wrong
    • I've done something wrong in my schematic

    More investigation is required.

    I will most likely use PCBWay again. The prices and quality are not much different from JLCPCB, but PCBWay has the following advantages:

    • Delivery is much cheaper through PCBWay for me - JLCPCB charges $30 "remote fee" since I don't live in a major city
    • The PCBWay Kicad plugin is very slick - you click a button and the order gets put into your cart ready for checkout

    When I first started ordering PCBs, it was different - PCBWay delivery was the same for both, and JLCPCB's manufacturing fee was cheaper. So I started sending the finished boards to my sister-in-law in Melbourne and waiting a few weeks until I could get them from her. But now that I've tried PCBWay and got the PCBs delivered directly for the same price, I will definitely continue to use them.

    Below you can see the excellent quality of the PCBs. My LED module PCB is on the left. On the right is a different project that is more complicated and uses ICs with finer pitch leads. I could not find any flaws (only some dust!).