I created the main board in the same pattern as the original. That made for quite an expensive prototype as there is a lot of empty space. This size is needed to fit the tactile switches in their proper places. Now that I have Revision 2 up and running, a write up of what I have learned along the way is over due.
The assembly was not without issues. There were some lessons to learn with KiCad and circuit design and layout as I did make some mistakes but I was able to identify the issue and make some corrections. Here are some of the things I picked up along the way
Check the pin outs
This might sound like an obvious thing and it hind-sight, it was. Complacency crept in on more than one occasion and I did not verify the pin allocations between the datasheet, symbol and footprint for the linear regulator. As it was a three pinned device, I only needed to reset it and run a bridge to ground.
I did not factor any indicator LEDs on the main board. While this is not a mistake, the addition of an LED to blink to show that something is happening is well worth the few seconds it takes to model it in the schematic and layout.
Don’t leave GPIO pins unconnected
This is just to say for any prototyping board, it would be worthwhile to expose any spare pins to headers, and or coupled with 0Ω resistors. When troubleshooting, you never know when you might need something. Of course in the production board, these would not be populated.
Getting Things up and Running
Once the power rails were reading the correct voltage, I connected in the RTC module. This fired up OK. I.e. Its LED lit up for a second. This is when I realised I was missing a heartbeat LED. I simply connected a piece of through hole lead to Port B0. This was the output that was configured as the heartbeat on the myAVR development board.
Using the procedure I used for the previous boards, I tested the connection between the PC and the AVRISP mkII using the Atmel Studio. If I could read the serial number of the micro, then I knew I was in good form.
I flashed the program I was using on the myAVR Dev board. Straight away the heartbeat started pulsing. Another good sign. The display did not react, or when it did, it was with garbage.
The issue with the display module as due to a mismatch between the main board and the display module. Since communication was OK to the RTC, I could assume that the SPI was largely OK. The obvious place the issue would be was with the actual signalling and or timing.
This issue has kept me occupied for some time. The biggest help was the Salea Logic Analyzer. To be able to capture the signals and have the digital values interpreted is a huge advantage. I could read the values being sent to the clock and display to ensure they were correct. I was able to tweak the code so that I could match the SPI specifications described on the RTC datasheet. I used this as a base to then configure the display module. Everything started to fall into place then and the display was more stable.
I found that to get the flexibility out of BASCOM, I needed to set up the Master i.e. the main board using software controlled SPI. Whereas, I could simply rely on the hardware SPI for the slave (display board).
Main Board SPI Setup
Fir the main board, the software controlled SPI was preferred since I could then use the SS = None property on the configuration. I then had to allocate my own chip-select lines for each of the RTC and the display module.
Config Spi = Soft , Din = Pinb.4 , Dout = Portb.3 , Ss = None , Clock = Portb.5 , Setup = 40 , Mode = 1 Display_ss Alias Portb.2 Config Display_ss = Output : Display_ss = 1 Dcf_ss Alias Portb.1 Config Dcf_ss = Output : Dcf_ss = 1 Spiinit
Display Board SPI setup
The key to the display board setup was to use the Master = no to ensure that this would be configured as a slave. All pin allocations were as per the datasheet for the micro controller.
Config Pinb.4 = Output Config Pinb.3 = Input ' MISO Config Spi = Hard , Interrupt = On , Data Order = Msb , Master = No , Polarity = Low , Phase = 0 ' , Clockrate = 128 Spiinit On Spi Spi_isr 'Nosave
In principle, things were good. I know I can flash the display module and I know I can flash the main board. I also know that communication is happening between the main board and the RTC.However there is still a niggling problem between the controller board and the display unit. After a while, the data seems to get out of sync and the display starts to display wrong values. Examining the SPI signals, I could be satisfied that the data presented and received by the display module is correct. There is something else happening inside the display module that is causing the information to be gabled. This is where I am reaching another boundary on my tool-set. The myAVR and the AVRISP MkII do not support any debugger. This is a set of tools I have yet to expose myself to and learn. Thinking around the problem, I am sure that this is some type of synchronisation issue. The actual cause, I can’t be sure. One thought would be some interference with the interrupt service routines. Since the data presented to and received by the display module is correct, I am willing to exclude the actual controller from the equation, for the moment. The problem has lead to some optimisations on the display module. One of the first improvements was seen when removing the NOSAVE from the On spi Spi_isr statement. This reduced the Spi_isr down to the following
Spi_isr: Set Rbit Mosi = SPDR Return
The same routine as described in a previous blog entry also contained logic to arbitrate whether the incoming data was a register address or a value for the register. in fact, this was always a concern. How to reliably determine the name from the value. The very first entry after start-up is going to be an address. After that, if something happens to the timing, it is not so clear cut.
After trying several ways to analyse the problem and make changes that were not always successful, I have determined the most effective way would be to flag the address. This means the API to the display module has now changed such that the first byte send to it, as address, must have the most significant bit set. This is a major improvement on reliability, but still no solution!
Do If Rbit = 1 Then Reset Rbit Spdr = Mosi If Mosi.7 = 1 Then Idx = Mosi And &B00001111 Else Register(idx) = Mosi ' Assign the data to the register Select Case Idx ' Based on the register/value, set the affected variables Case Hours_10: Digits(1) = Register(idx) ...
There are still some issues to solve with this. For the above change, the controller board was not considered. However, the problem now comes back to the controller board to understand what the interaction is between the RTC, the controller board and the display board really is. Only once in a while at the transition of a minute, the display will be corrupted for a second or two. This does not happen often. Perhaps three to four times in an hour. But it shows there is still some form of timing race condition happening.
Where to from here?
I am happy that the communication is happening but I can’t call the job complete as there are some odd issues still persisting. I could work around them by sending only one byte rather than two so that the high end nibble is the address and the low end nibble is the value to be set. This would work for most of my values, but no all. Besides – that would be a work around and not a solution. I need to find a way to better understand what is happening with the data between the RTC, main board and display module such that the display modules register address and values are being skewed. At least that is my current understanding of the issue.