Address Trap and Strings

[JimKueneman]

What does this function do? I am having problems with Address Traps that seems to get worse as I change how I am defining string parameters. It is difficult to pin down what is happening but when the Trap returns it returns on the line after where I marked <<<< HERE <<<<<<

I am guessing it means something to string.

Jim

Code: Select all

___CS2S:
0x3360	0xFA0000  	LNK	#0
0x3362	0x000000  	NOP
0x3364	0x000000  	NOP
;__Lib_System.mpas,16 :: 		
;__Lib_System.mpas,18 :: 		
L_loopCS2Ss:
;__Lib_System.mpas,19 :: 		
0x3366	0x784131  	MOV.B	[WREG1++], WREG2  <<< HERE <<<<<<<<<<<
;__Lib_System.mpas,20 :: 		
0x3368	0xE24004  	CP0.B	WREG2
;__Lib_System.mpas,21 :: 		
0x336A	0x320002  	BRA Z	L_CS2Send
;__Lib_System.mpas,22 :: 		
0x336C	0x785802  	MOV.B	WREG2, [WREG0++]
;__Lib_System.mpas,23 :: 		
0x336E	0x37FFFB  	BRA	L_loopCS2Ss
;__Lib_System.mpas,24 :: 		
L_CS2Send:
;__Lib_System.mpas,26 :: 		
L_end___CS2S:
0x3370	0x000000  	NOP
0x3372	0xFA8000  	ULNK
0x3374	0x060000  	RETURN
; end of ___CS2S

[zristic]

Hi,
Sorry for the delay.
Can you please provide us the smallest code which is causing this trap?
The trap in this case means you are accessing an invalid address with indirect addressing, for example [WREG1++] traps if WREG1 contains an odd address.

[JimKueneman]

Thanks for the reply. I just updated my ticket yesterday on this (sort of). The problems all went away after I removed a function that was passing multiple strings as parameters and returning a string result. I just got stung by a problem where the wrong values were being passed in a function call. The new one was obvious as they were bytes so seeing they were wrong was easy. My bet is this problem was because of the same issue, the parameter passing was getting messed up. By changing one of the Bytes to a Boolean causes the compiler to do something different and pass the correct values. I also uploaded that version to help see the difference.

The example program is not small and needs a custom CCA to run in hardware but my expectation is you can track down what is happening by my complete source (that compiles) and see where the compiler is failing through the the listing output.

Jim

[JimKueneman]

Just an update for everyone who is interested. The problem was reproduced and should be fixed in the next release. Be aware paraemeter passing may be troublesome under some conditions (maybe Filip could enlighten us on the conditions ).

Jim

[Dany]

maybe Filip could enlighten us on the conditions .

mE does not work this way. Could you please show the examples where it went wrong in your code? I am starting with the dsPic 30/33 and pic24 compiler and using P24, and I do not want to spend again days to figure out why my code is not working while in fact it is Ok.

[JimKueneman]

I don't know how to avoid this problem. I have been working on my program for about 6 months now and have over 200 function in this large program. I have found only two functions that have failed. What it may be is both function passed identical types in the parameter list:

Code: Select all

procedure Foo(A: Byte; B: Byte);
function(var A: string; var B: string): string

I have not spent time to investigate if this is the cause. Since it will be fixed soon figuring this out got pushed down the priority list

I have another problem with parameter passing in v4.8, my money says is is the same problem as it has to do with the string parameter passing problem. This time it is from within the interrupt.

I know this is a huge program but I am hoping with the listing file and pascal source you can see what is not being generated in the listing correctly.

Look in the NMRA_DCC.mpas file and find this function:

Code: Select all

procedure Direct_LoadMessage(BufferPtr: PDCCBufferInfo; ServiceMode_State: Byte; OpCode: Byte; PreambleCount: Byte);
var
i: Integer;
begin
  BufferPtr^.TX_TransmittingMessage.MessageBytes[0] := OpCode or (ServiceModeInfo.Buffer.Address shr 8);
  BufferPtr^.TX_TransmittingMessage.MessageBytes[1] := ServiceModeInfo.Buffer.Address and Word($00FF);
  if (ServiceMode_State = STATE_SERVICEMODE_DIRECT_INSTRUCTION_BIT_WRITE) or (ServiceMode_State = STATE_SERVICEMODE_DIRECT_INSTRUCTION_BIT_READ) then
    BufferPtr^.TX_TransmittingMessage.MessageBytes[2] := %11100000 or ServiceModeInfo.Buffer.Value
  else
    BufferPtr^.TX_TransmittingMessage.MessageBytes[2] := ServiceModeInfo.Buffer.Value;
  BufferPtr^.TX_TransmittingMessage.Flags := 3;
  BufferPtr^.TX_XOR_Byte := 0;
  for i := 0 to 2 do
    BufferPtr^.TX_XOR_Byte := BufferPtr^.TX_XOR_Byte xor BufferPtr^.TX_TransmittingMessage.MessageBytes[i];
  BufferPtr^.TX_PreambleBitCount := PreambleCount;
  Inc(ServiceModeInfo.TotalSent);
end;

Scroll down a few line to see where it is called:

Code: Select all

procedure Direct_Instruction(ServiceMode_State: Byte; InstructionCode: Byte; BufferPtr: PDCCBufferInfo; PreambleCount: Byte);
begin
  if ServiceModeInfo.iStateMachinePacket = 2 then // Start looking for an ACK from the decoder after the packet sent to the decoder
  ServiceModeInfo.Flags.PROGRAMMING_ACK_STATE_SCAN_FOR_ACK_BIT := 1;

  if ServiceModeInfo.Flags.PROGRAMMING_ACK_STATE_DETECTED_BIT = 1 then // Break off once a ACK is detected
  begin
    case ServiceMode_State of
      STATE_SERVICEMODE_DIRECT_INSTRUCTION_WRITE,
      STATE_SERVICEMODE_DIRECT_INSTRUCTION_BIT_WRITE : Direct_HandleAckDetected(BufferPtr, STATE_SERVICEMODE_DIRECT_WRITE_RECOVER_CYCLE, PreambleCount);
      STATE_SERVICEMODE_DIRECT_INSTRUCTION_READ,
      STATE_SERVICEMODE_DIRECT_INSTRUCTION_BIT_READ : Direct_HandleAckDetected(BufferPtr, STATE_SERVICEMODE_DIRECT_SEQUENCE_COMPLETE, PreambleCount);
    end
  end else
  begin
      Direct_LoadMessage(BufferPtr, ServiceMode_State, InstructionCode, PreambleCount); << CALLED HERE

So if I run this program on my custom CCA and set a breakpoint on

Code: Select all

Direct_LoadMessage(BufferPtr, ServiceMode_State, InstructionCode, PreambleCount);

Here are the passed parameter values:

BufferPtr = 0x0906; Correct
ServiceMode_State = 12; Correct
InstructionCode = 116; Correct
PreambleCount = 20; Correct;

I now step into Direct_LoadMessage

BufferPtr = 0x0906; Correct
ServiceMode_State = 12; Correct
InstructionCode = 12; INCORRECT!!!!!!!!!!!!!!!!!!!!
PreambleCount = 20; Correct;

Here is the generated code setting up the passed registers into the function:

Code: Select all

;NMRA_DCC.mpas,715 :: Direct_LoadMessage(BufferPtr, ServiceMode_State, InstructionCode, PreambleCount);
0x31EC 0x781F8A PUSH WREG10
0x31EE 0x781F8A PUSH WREG10
0x31F0 0x78050C MOV WREG12, WREG10
0x31F2 0x7805CF POP WREG11
0x31F4 0x78460B MOV.B WREG11, WREG12
0x31F6 0x07F919 RCALL NMRA_DCC_Direct_LoadMessage
0x31F8 0x78054F POP WREG10

And the code to at the entry point into the function

Code: Select all

NMRA_DCC_Direct_LoadMessage:
0x242A 0xFA0000 LNK #0
;NMRA_DCC.mpas,672 :: begin
;NMRA_DCC.mpas,673 :: BufferPtr^.TX_TransmittingMessage.MessageBytes[0] := OpCode or (ServiceModeInfo.Buffer.Address shr 8);
0x242C 0x450164 ADD WREG10, #4, WREG2
0x242E 0x8071B0 MOV _ServiceModeInfo+26, WREG0
0x2430 0xDE00C8 LSR WREG0, #8, WREG1
0x2432 0xFB800C ZE WREG12, WREG0
0x2434 0x700001 IOR WREG0, WREG1, WREG0
0x2436 0x784900 MOV.B WREG0, [WREG2]
;NMRA_DCC.mpas,674 :: BufferPtr^.TX_TransmittingMessage.MessageBytes[1] := ServiceModeInfo.Buffer.Address and Word($00FF);
0x2438 0x450064 ADD WREG10, #4, WREG0

Something seems wrong in the setup of the register:

Code: Select all

;NMRA_DCC.mpas,715 :: Direct_LoadMessage(BufferPtr, ServiceMode_State, InstructionCode, PreambleCount);
0x31EC 0x781F8A PUSH WREG10
0x31EE 0x781F8A PUSH WREG10
0x31F0 0x78050C MOV WREG12, WREG10
0x31F2 0x7805CF POP WREG11

Why is WREG10 pushed to the stack twice and popped into WREG11. Up to the pop WREG11 contains the correct value for OpCode (116). After the pop 116 is not in any registers.

The way I fixed this was to changed the type of one of the parameters, the first Byte is now a Boolean;

Code: Select all

procedure Direct_LoadMessage(BufferPtr: PDCCBufferInfo; IsBitMode: Boolean; OpCode: Byte; PreambleCount: Byte);
var
i: Integer;
begin
  BufferPtr^.TX_TransmittingMessage.MessageBytes[0] := OpCode or (ServiceModeInfo.Buffer.Address shr 8);
  BufferPtr^.TX_TransmittingMessage.MessageBytes[1] := ServiceModeInfo.Buffer.Address and Word($00FF);
  if IsBitMode then
    BufferPtr^.TX_TransmittingMessage.MessageBytes[2] := %11100000 or ServiceModeInfo.Buffer.Value
  else
    BufferPtr^.TX_TransmittingMessage.MessageBytes[2] := ServiceModeInfo.Buffer.Value;
  BufferPtr^.TX_TransmittingMessage.Flags := 3;
  BufferPtr^.TX_XOR_Byte := 0;
  for i := 0 to 2 do
    BufferPtr^.TX_XOR_Byte := BufferPtr^.TX_XOR_Byte xor BufferPtr^.TX_TransmittingMessage.MessageBytes[i];
  BufferPtr^.TX_PreambleBitCount := PreambleCount;
  Inc(ServiceModeInfo.TotalSent);
end;

And called it like this:

Code: Select all

procedure Direct_Instruction(ServiceMode_State: Byte; InstructionCode: Byte; BufferPtr: PDCCBufferInfo; PreambleCount: Byte);
var
IsBitMode: Boolean;
begin
  if ServiceModeInfo.iStateMachinePacket = 2 then // Start looking for an ACK from the decoder after the packet sent to the decoder
  ServiceModeInfo.Flags.PROGRAMMING_ACK_STATE_SCAN_FOR_ACK_BIT := 1;

  if ServiceModeInfo.Flags.PROGRAMMING_ACK_STATE_DETECTED_BIT = 1 then // Break off once a ACK is detected
  begin
    case ServiceMode_State of
      STATE_SERVICEMODE_DIRECT_INSTRUCTION_WRITE,
      STATE_SERVICEMODE_DIRECT_INSTRUCTION_BIT_WRITE : Direct_HandleAckDetected(BufferPtr, STATE_SERVICEMODE_DIRECT_WRITE_RECOVER_CYCLE, PreambleCount);
      STATE_SERVICEMODE_DIRECT_INSTRUCTION_READ,
      STATE_SERVICEMODE_DIRECT_INSTRUCTION_BIT_READ : Direct_HandleAckDetected(BufferPtr, STATE_SERVICEMODE_DIRECT_SEQUENCE_COMPLETE, PreambleCount);
      end
    end else
  begin
  IsBitMode := (ServiceMode_State = STATE_SERVICEMODE_DIRECT_INSTRUCTION_BIT_WRITE) or (ServiceMode_State = STATE_SERVICEMODE_DIRECT_INSTRUCTION_BIT_READ);
  Direct_LoadMessage(BufferPtr, IsBitMode, InstructionCode, PreambleCount);

Here are the passed parameter values of a test:

BufferPtr = 0x0906; Correct
IsBitMode = False; Correct
InstructionCode = 116; Correct
PreambleCount = 20; Correct;

I now step into Direct_LoadMessage

BufferPtr = 0x0906; Correct
IsBitMode = False; Correct
InstructionCode = 116; CORRECT THIS TIME!!!!!!!!!!!!!!!!!!!!
PreambleCount = 20; Correct;

Again I know this is a large program but it seems that this should be enough detail to track down the problem. This is a nasty problem that can really cause strange bugs in user code and waste a lot of time tracking down.

Thanks,
Jim

[Dany]

This is a nasty problem that can really cause strange bugs in user code and waste a lot of time tracking down.

Indeed! Thanks for the valuble information! It can save me a lot of time.

[Dany]

Hi Jim,

Do you have the "SSA optimisation" on or off? Does it help to switch it off?

[JimKueneman]

Hi Dany,

never realize you asked a question here. It did not matter. The dsPIC compiler has been unfriendly to me in parameter passing. I am not sure if it is because of the low number of users for the compiler or I just have a different mindset in writing code than most


Here is my plan:

http://www.mikroe.com/forum/viewtopic.php?f=106&t=32939

Jim

[Dany]

Hi Dany,
never realize you asked a question here. It did not matter. The dsPIC compiler has been unfriendly to me in parameter passing. I am not sure if it is because of the low number of users for the compiler or I just have a different mindset in writing code than most
Here is my plan:
http://www.mikroe.com/forum/viewtopic.php?f=106&t=32939

Thanks for the info.
I asked the question because when I saw some unexpected behaviour using PIC24, I switched off the SSA optimisation, and until now all my problems could be solved with that. There was a chance that would work in your case too, but it did'nt...
I did only start very recently with PIC24, and I made no actual applications with that PIC family yet. Once I start to do that I clould have more "difficult" problems also I assume.
I was astonished that SSA was a problem in the very first tests I've done with PIC24.
Is the dsPIC24/33 and PIC24 mP compiler not so much used? There are anyway not as much forum posts as for PIC...