Completely at a loss...

[JimKueneman]

Thanks for looking at it Vcc. I have found the cause of the timing issue. It is because of not using the result of the function. I changed the function to a procedure and the timing issue went away. The rest of the issues still persist, but that is for tomorrow....

Jim

[JimKueneman]

Ok I need you smart guys.......

Here is what is going on:

In my main loop I am doing this test as I have said repeatedly..

Code: Select all

if OPStack.State and OPS_PROCESSING <> 0

Now in the 100ms interrupt driven timer I am doing this:

Code: Select all

procedure OPStackCore_Timer;
var
  i: Integer;
  Node: PNMRAnetNode;
begin
  if OPStack.State and OPS_PROCESSING <> 0 then
  begin
    // Only the Login gets the 100ms update no reason for higher resolution elsewhere
    for i := 0 to NodePool.AllocatedCount - 1 do
    begin
      Node := NodePool.AllocatedList[i];
      Inc(Node^.Login.TimeCounter_100ms);
    end;

    Inc(OPStack._1sCounter);
    if OPStack._1sCounter > 10 then      // 1s-1.1s
    begin
      OPstack._1sCounter := 0;
      Inc(Node^.UserWatchdog_1s);
      OPStackBuffers_WatchdogTimer_1s;
      AppCallback_Timer_1s;
      {$IFDEF SUPPORT_TRACTION} TractionProtocolTimerTick_1s(Node);{$ENDIF}
    end;
  end;
end;

Notice I am using the same test in the interrupt, accessing the same field of the record. What is appears is happening is these two tests are stomping on each other.... If I disable the timer during the time I do the test in the main loop my code all works as expected.... Up to the point I have tested it...

After a bit more testing it is more than just that simple test. It has to do with me using variables and record fields in the main loop that I am updating (just a simple increment for watchdogs of a byte field) in the interrupt....

I have seen a fair number of posts with people having issues with PIC32 interrupts.

This all works fine in the dsPIC architecture. I am needing a MIPS lesson I think... I know these operations are not atomic but I expected the actual update to the register (variable) is done in a single cycle.... This appears to be an incorrect expectation. Can someone set me straight with this micro controller architecture......

Jim

[VCC]

Hi Jim,
can you test something please ?

Code: Select all

procedure MCU_Enable100msTimer;
begin                      
  T5CON       := 0x8070;
  T5IE_bit    := 1;
  T5IF_bit    := 0;
  T5IP0_bit   := 0;
  T5IP1_bit   := 1;
  T5IP2_bit   := 0;
  PR5         := 31250;
  TMR5        := 0
end;

Replace with

Code: Select all

procedure MCU_Enable100msTimer;
begin                      
  T5CON       := 0x0070; ////changed from 0x8070 to 0x0070, because 0x8070 starts the timer with unknown values
  T5IE_bit    := 1;
  T5IF_bit    := 0;
  T5IP0_bit   := 0;
  T5IP1_bit   := 1;
  T5IP2_bit   := 0;
  PR5         := 31250;
  TMR5        := 0;
  T5CON.15 := 1; //enable timer here, after setting it
end;

[VCC]

I don't say yet this leads to an exception, but...
From errata:

43. Module: CPU
When both Prefetch and Instruction Cache are
enabled, a Data Bus Exception (DBE) may occur if
an interrupt is encountered by the CPU while it is
accessing constant data (not instructions) from
Flash memory.

From mikroPascal help:

By default the MCU is configured as follows :

Cache Enabled,
Prefetch enabled (for executable code and constants),

[JimKueneman]

I will check that tonight.

I had a shower revaluation this morning. It seemed like the context saving going into the interrupt could be causing what I was seeing......

I have SRS set to interrupt level 7 for the shadow registers for context saving...

All sorts for creepy and crazy things happen at run time.

Code: Select all

procedure OPStack_100ms_Timer(); iv IVT_TIMER_5; iLevel 2; ics ICS_AUTO;

Code: Select all

_OPStack_100ms_Timer:
;PIC32MX_Basic.mpas,14 ::                 begin
ADDIU        SP, SP, -16
SW        R30, 12(SP)
MFC0        R30, 12, 2
SW        R30, 8(SP)
MFC0        R30, 14, 0
SW        R30, 4(SP)
MFC0        R30, 12, 0
SW        R30, 0(SP)
INS        R30, R0, 1, 15
ORI        R30, R0, 2048   <<<<<<<<<
MTC0        R30, 12, 0
ADDIU        SP, SP, -4
SW        RA, 0(SP)

Code works as expected....

Code: Select all

procedure OPStack_100ms_Timer(); iv IVT_TIMER_5; ics ICS_AUTO;

Code: Select all

_OPStack_100ms_Timer:
;PIC32MX_Basic.mpas,14 ::                 begin
ADDIU        SP, SP, -16
SW        R30, 12(SP)
MFC0        R30, 12, 2
SW        R30, 8(SP)
MFC0        R30, 14, 0
SW        R30, 4(SP)
MFC0        R30, 12, 0
SW        R30, 0(SP)
INS        R30, R0, 1, 15
ORI        R30, R0, 64512     <<<<<<<<<<<
MTC0        R30, 12, 0
ADDIU        SP, SP, -4
SW        RA, 0(SP)

Explanation?

Jim

[JimKueneman]

Wow what a battle.... I finally have my library working...... Here is what I know to save others some time.

1) There is a bug in the compiler if you define a function and use it without assigning the result to anything
2) DO NOT use the iLevel keyword in an interrupt UNLESS you are using the ics ICS_SRS keyword and using the shadow registers
3) iLevel used with ics ICS_AUTO if it uses defaults to ICS_SOFT or ics ICS_SOFT will cause issues with the registers being saved correctly on entry into the interrupt

Jim

[JimKueneman]

Vcc

Thanks for the tips on the errata. I have also implemented your suggestions just for good measure.

Jim

[VCC]

Wow what a battle.... I finally have my library working...... Here is what I know to save others some time.

1) There is a bug in the compiler if you define a function and use it without assigning the result to anything
2) DO NOT use the iLevel keyword in an interrupt UNLESS you are using the ics ICS_SRS keyword and using the shadow registers
3) iLevel used with ics ICS_AUTO if it uses defaults to ICS_SOFT or ics ICS_SOFT will cause issues with the registers being saved correctly on entry into the interrupt

Jim

This is good to know. I recommend reporting this to mikroe in a support ticket, because they may not look at this post right now.

[JimKueneman]

There is one open that I keep updating pointing to this thread.

Jim

[jpc]

Jim,
i have not been over all your library and have not found all initialisations but there might be an issue with the interrupt priority settings: ME has provided us this Interrupt Assistant tool which suggest dealing with the prioritylevel but this is not true, the settings we put here is used by the compiler to decide about how to deal with context savings .
If this priority level does not correspond with the settings in the priority registers we mislead the compiler and strangest things may happen.
the ICS setting is probably best set to AUTO with the exception of one critical ISR that would need to run fastest as possible, probably irrelevant for this application.

[VCC]

Hi jpc,

If this priority level does not correspond with the settings in the priority registers we mislead the compiler and strangest things may happen.

I also forgot about it. It's in the help:

Interrupt Coding Requirements
In order to correctly utilize interrupts and correctly write the ISR code, the user will need to take care of these things :

Write the Interrupt Service Routine. You may use Interrupt Assistant to easily write this routine.
Initialize the module which will generate an interrupt.
Set the correct priority and subpriority for the used module according to the priorities set in the Interrupt Service Routine.
Enable Interrupts.

[JimKueneman]

Funny you should mention that. Just before going to sleep last night I had that thought.

Here is my interrupt:

Code: Select all

procedure OPStack_100ms_Timer(); iv IVT_TIMER_5; iLevel 2; ics ICS_AUTO;
begin
  T5IF_bit := 0;
  OPStackCore_Timer;    
  LATF12_bit := not LATF12_bit;
end;

Here is the initialization:

Code: Select all

procedure MCU_Enable100msTimer;
begin                      
  T5CON       := 0x8070;
  T5IE_bit    := 1;
  T5IF_bit    := 0;
  T5IP0_bit   := 0;   // Set interrupt Priority to 2
  T5IP1_bit   := 1;
  T5IP2_bit   := 0;
  PR5         := 31250;
  TMR5        := 0
end;

It looks like I did the right thing does it not?

That causes all kinds of issues until I did this:

Code: Select all

procedure OPStack_100ms_Timer(); iv IVT_TIMER_5; ics ICS_AUTO;
begin
  T5IF_bit := 0;
  OPStackCore_Timer;   
  LATF12_bit := not LATF12_bit;
end;

Jim

[VCC]

Code: Select all

  T5IP0_bit   := 0;   // Set interrupt Priority to 2
  T5IP1_bit   := 1;
  T5IP2_bit   := 0;

It's there, hidden in plain sight.
Is anything as expecting after removing iLevel 2 ?

[JimKueneman]

It's there, hidden in plain sight.
Is anything as expecting after removing iLevel 2 ?

Yes, after I removed iLevel 2 from the interrupt (and iLevel 6 from the CAN interrupts) my 45k library works perfectly.

I have not tried using the shadow registers yet.

Jim