We had a report of the dial-to-open system on a 4G GSM intercom not working periodically using a Vodafone Ireland SIM. Everything else about the unit was working perfectly so we had to investigate. TLDR; it was working fine... perhaps a wiring issue
We set about writing some firmware that could log the relevant information and allow us to see what happens within the software from our office in Liverpool. The actual GSM intercom was in another country but that doesn't matter as we can see the inner workings from anywhere. In fact the server we use for it to connect to is in London and we view this server here in Liverpool!
These intercoms use a PIC16F18857 chip written in assembly with absolute code and fixed memory locations... the hardest but most space efficient way of writing firmware. This stuff isn't easy!
Trace System
Our firmware features a trace system so we can see what the program has been doing. We store a code in a certain part of the memory every time a subroutine or code portion has been run. This means we can build a picture of what the program was doing at any point.
For example we store the hex code "0xBF" in the trace memory when the RING notification comes through from the network. Similarly we store "0x4C" when the caller ID command '+CLIP:' comes from the network
do_ring
bcf lLED1
movlw 0xBF
call trc
goto maindo_clip
movlw 0x4C
call trc
movlp 0x38
goto save_clip
clip_stored
We also wanted to see the actual +CLIP message from the network to see why it didn't work so we stored this in an unused memory location
save_clip
movlw 0x25
movwf FSR1H
movlw 0xA0
movwf FSR1L
movf FSR0L,0
movwf temp
movlw 0x50
movwf tmp
movlw 0x20
movwf FSR0L
save_clip_loop
moviw FSR0++
movwi FSR1++
decfsz tmp,1
bra save_clip_loop
movf temp,0
movwf FSR0L
goto clip_stored
The firmware with the debug code was loaded into the intercom and it was returned to normal operation. However, now we can read the CLIP messages over the internet and view exactly what happens when a call is made to the intercom phone number.
flash 20435xxxxx g:\cbld\INT817.hex
Updating 20435xxxxx with file g:\cbld\INT817.hex
Don't forget to clear flash! Type 'clear flash'
Converting Image
Image Stored
>Flash Result: 00000000CC8C3582 CALC: 8C35
Now to try it!
The number was wrung and the following trace was extracted. The important traces are in bold.
9B goto do_ring RING notification from network
BF do_ring Passed to RING handler
08 GSM_result
02 csq_loaded into TS0
96 goto do_clip +CLIP message received
4C do_clip Passed to CLIP handler
DA Event 5A... 0x3A event... Accept Call Number has access
D4 Event 54 Unknown event
4B call in progress The phone is still ringing
77 update_RLY The output relay is activated to open
4A reject_it The call is rejected
17 send_chip_event The remote webpage is updated
78 force_IO Part of webpage update
69 main3 Do send data to network
F7 wait_for_prompt (Send Control Table)
77 update_RLY Relay pulse ended so close relay
F2 no_prompt_TO (Send Control Table)
6B no GT (arrow) character
78 force_IO Send new relay state to webpage
69 main3
The +CLIP message was also as expected
0920 2B +
0921 43 C
0922 4C L
0923 49 I
0924 50 P
0925 3A :
0926 20
0927 22 "
0928 2B +
0929 34 4
092A 34 4
092B 37 7
092C 39 9
092D 33 3
092E 33 3
092F 34 4
0930 35 5
0931 33 3
0932 39 9
0933 33 3
0934 30 0
0935 22 "
0936 2C ,
0937 31 1
0938 34 4
0939 35 5
093A 2C ,
093B 2C ,
093C 2C ,
093D 2C ,
093E 30
So on this occasion it worked perfectly... which is the problem with periodic faults. There will be a part 2 if we find an issue with the caller ID or firmware.