I left the prototype running over several days and suddenly realized it was not working. The beeper on the A/C control panel had not sounded, and the room temperature was too high. I went over to the desk unit, touched the screen, and suddenly it started working. Hmm.
During my initial debugging, I decided that the screen being on all the time was undesirable. It created a lot of heat in the unit. Since I had not received the reworked board, I programmed the Nextion to sleep with inactivity. This turns the display off, and more or less halts the onboard processor after a certain amount of inactivity. It appears that after a couple of days of continuous sleeping, the PSOC gets stuck somewhere. It no longer commands the AC unit.
Laying a Trap
What you may or may not know, the PSOC KitProg debugger stub along with PSOC Creator, has the ability to halt a running program and debug it. So, my first step in the process is to set up the KitProg so I can catch the errant program.
First, I placed it on a notebook on a laser printer in my workshop, as you can see here:
In order to attach the debugger, I soldered in 0.1″ single post pins, and plugged in ribbon cable connectors into both sides. (Previous posts covered the ribbon connectors). Here is a closeup of the debug stub plugged in and ready to be used:
Note that you should keep it powered up, even though it is not communicating with the PSOC. This will prevent it from accidentally resetting the PSOC, stopping your long term debug watch.
Connect To The Unit
If you are using a VM, make sure the PSOC debugger stub USB port is attached to it. Next, load the program currently running on the PSOC into the PSOC Creator. Make sure it is the version loaded into the board! If not, your debug attempt will be useless. The PSOC 5 carries no information regarding the code it is running, so neither it nor the debugger knows if you are looking at the right source code.
With the right code loaded, select “Attach to Running Target: from the Debug menu:
You will get a screen like this, if the KitProg is attached to your VM (or plugged into your Windows computer):
The reason you have the selection is due to the fact that several PSOCs could be attached through a single JTAG, and you would have to choose the right unit. Note the “Halt target on attach” checkbox. That checkbox does nothing. If you uncheck it, it halts the PSOC when the attach happens. If you check it, it halts the PSOC when the attach happens. I’m sure it is something no one ever notices or cares about, or it would have been fixed by now.
Click the “OK” button, and you will be shown where the PSOC is in its loop. In my case, it halted at the USB Uart code:
There are several things of interest here. The memory window shows you what is in memory at absolute addresses. You can change that memory if you wish. The “Call Stack” window allows you to double click on the Level column row to take you to the code for that call. In this case, clicking on the “1” will show you the following:
If you look carefully, you will see that the Code in the “Stopped by Debugger” image is in yellow, and the “Call Stack Level 1” image is in green. Yellow marks where you currently are in the code, and Green marks where you came from.
Continue to Set the Trap
Pressing the “F5” key, or selecting the Debug->Resume Execution menu, or clicking on the green Right Arrow just above the “USBSerial.C” tab will cause the program to start executing again. At this point, you need to disconnect from the PSOC 5.
To do so, press the Blue Square, or press the Shift+F5 key combination, or select the Debug->Stop Debugging menu. The PSOC Creator disconnect, and you will see the green light on the Debugger Stub stop flashing. In our case, the blue light on the CY8CKit-059 board will be flashing. That is our indication the unit is ready for us to reconnect and catch it the next time it fails.
As indicated last post, the case has been redesigned. Here is a look at it:
If you think it looks rough, it is. I used very lax rules on it. I want a press fit, so the rougher the better. Believe it or not, I have found the “rough” look for plastic cases sitting on desks or night-stands looks much better than trying for a very smooth print.
This is due to the fact that for the low end printers, a smooth print is always marred by slight imperfections. So, going for the “rough” look ends up with a better esthetic.
The Nextion case files are here. The zip file contains a directory which has the Sketchup file and the STL file, which can be loaded into a 3D printer slicer program. If you examine the case in Sketchup, you will see that there are holes for hanging the unit on the wall, and several holes for LED, Power Cable, and Temperature sensor.
I wanted to cover building the new board and installing in the case this time, but since I have laid a trap for the failing code, I will have to wait to mount the unit. For now, I must exercise patience.
Next Time I hope to show you the captured error and what is done about it. I have suspicions. I believe the Nextion link is somehow “full,” and the PSOC is stuck waiting for something. Once the debugger tells me what, I will determine how to overcome this issue.