4G GSM Intercom Dial-to-Open investigation on Vodafone Ireland

Posted by Michael Beaver on

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 main
do_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.