XGATE troubles (using RISC)

[Pinhead]

In an effort to reduce the processing load on my 9S12X processors, I have moved modbus communication onto the XGATE processors using risc instructions, not C.  It is difficult finding anyone who doesn't use C.  Anyway, everything works fine, but after some time, say an hour, the communications all lock up.  Sometimes the whole processor seems locked up, but sometimes it is just communications.  I have thrown everything at this that I can think of.  I have tried using semaphores where I can, but the buffers need to be used by both processors, and anyway, it should be timed so that the buffers aren't needed at the same time. 

I guess the main question that I am most likely to get an answer to is:  what happens when both processors try to access a variable at the same time?  And is there a way to deal with such an error when it arises?  My program requires for the unit to still run without communication, so I can't just reset when there is no communication, or else I would face the possibility of permanent resetting.

Any help offered would be greatly appreciated.  I am in pretty deep.

[mac164]

CHRIS

1. You have lots of good advice in previous replies from the experts. However I have an Oddball you might consider.

2. Sense you are programing in XGATE Assembly you may have the following Coding Problem:

The XGATE RM states that the following statement:

     LDW     R2,Address          ;Will load the contents of Address - It won't

     Rather it will load the Effective Address of 'Address' like the instruction:

     LDW     R2,#Address
     The XGATE Ref Manual is in Error

     To load the CONTENTS of 'Address' the follow two instructions are needed

     LDW     Rn,#Address

     LDW     R2,(Rn,R0)

3. If you are using this coding to acces a Semaphore, Perhaps this is the problem.

4. All XGATE Assembly programs should be scanned for this illegal/Error instruction.

5. 'C' programmers probably don;t get the error because the 'C' compliler is jury rigged to fix the problem.

6. Hope you find the problem

Regards

     Leonard

[HSW]

Hello Leonard,

Which XGATE RM are you referring to?

According to any S12X RM (e.g. MC9S12XDP512 RM), "LDW  R2,Address" is not a valid XGATE instruction. The XGATE has a fixed instruction length of 16 bit. It is not possible to encode full 16 bit address into a XGATE instruction.

"LDW R2,#Address" is shortcut for the instruction sequence "LDL R2,#(Address&$FF), LDH R2,#(Address>>8)". The S12X RMs don't define a shortcut for "LDW R2, Address", because any suitable instruction sequence would need to alter a second GPR.

[mac164]

HSW:

I don't have a 512X and I haven't read the RM. I am referring to the XGATE Assembler RM (I don't have the RM # in front of me, but you can find it on the Freescale Web). I have lately been programming the 100XEP, XHY and XHZ vesions. I use the XGATE assembler RM when programming in Assembly. The RM's, for the chips that I memtion here, shows only a cusorary introduction into the XGATE assembler.

However the XGATE Assembler (either the Motorola or Freescale versions) does have a LDW instruction that loads a 16 bit address. It explains both a effective address using the # sign and the contents of the address without the # sign. I use the LDW instruction all the time, works fine.

I will download the 512X RM to see what it says,h but I would thing that you should refer to the XGATE assembler RM, just like you would and read the S12X Assembler RM for CPU12 instrustions. The various chip RM's, in my experience, can not be used as an Assembly referenece manual.

The Error, in both manuals, is that LDW always load the 16 bit effective address.

At a friends request I put an example of a XGATE Serial Transponder on the Forum. Download it and you will

see a lot of LDW  Rn,#Address and perhaps other Instructions that the 512X RM manual doesn't include.

I would appricaite any further feedback.

Regard

     Leonard

UPDATE: I have read the XDP RM and I see where your coming from. In the past the RM's I have read were outdated and did not have the

updated/correct information. The XGATE RM manual that I have been using is 'FREESCALE XGATE ASSEMBLER' Dated Feb 2008. (it's a carbon copy

of the 'MOTOROLA XGATE ASSEMBLER' of the same date. Chapter 6 has several errors: It includes the following CORRECT XGATE examples:

     LDW     Rn,#address          ; Load the effectives 16 bit address

     LDW     Rn,#$xxxx            ; Loads the 16 Bit Immedaite value in Rn

     Note: These instruction work fine; the assembler converts them to LDH & LDL

Chapter 6 has the following ERRORS:

     LDW     Rn,Address          ; Loads the contents of 'Address'

     LDW     Rn,$56                 ; Loads the Contents of Address $56

     Note: Neither of these instructions are correct. The author of this manual was assuming that the XGATE operates like CPU12.

     The XGATE Assembler will accept these and will not flag them...

Conclusion: I learned XGATE Assembly on an OLD RM. (I noticed it had no Ref Number - just  name). Obviously Freescale needs to eliminate

this manual and issue an errata or note to cancel same. From now on I will read the latest Updated manuals.

Thanks HSW

Regards

Leonard 

Message was edited by: leonard mcreynolds

Message was edited by: leonard mcreynolds

[kef]

I suppose you are talking about S12XD/S12XA. And in S12XD reference manual Rev 2.21 you had to find these:

p202.

...Whenever the S12X_CPU and the RISC core access the same resource, the RISC core

will be stalled until the resource becomes available again 1)

1) (except PRU registers).

p683:

...XGATE access to PRU registers constitutes a special case. It is always granted and stalls the CPU

and BDM for its duration.

list of PRR registers is on p645

So when both cores access the same resource in exactly the same read/write cycle, one of cores is halted until another one completes R/W cycle. Who wins is each case is listed above, but you should study Ref.Man., maybe I missed something.

[Pinhead]

Edward, thanks for your reply.  I am fine with stalling.  It's the stopping I'm not ok with.  I guess I was under the impression that semaphores were sort of a life and death issue with the program.  This seems to indicate that is not the case, that it simply has to wait.  I have pored through this manual quite a bit, but had missed that line about stalling.  In general, I found the content to be a bit lacking as far as XGATE is concerned.

Mostly I was wondering if anyone had any sticking issues like this when using the XGATE.

[kef]

Chris,

I think it should be possible to stop MCU and inspect what program counters are pointing to and what's the state of relevant interrupt mask bits, buffer pointers and buffer flags. Anyway you need to figure why comms are dead. It's hard to lead you with so few details.

In general you need to use semaphore to prevent simultaneous accesses to each shared resource like some variable, some bit, interrupt mask register, interrupt flags register, and any other register. It is especially true for simultaneous write accesses. Since XGATE doesn't care what CPU is doing, CPU instructions are not so atomic any more. For example BSET instruction has separate  R and W cycles. BSET reads some byte, modifies it, then writes byte back. But XGATE can modify memory between BSET R and W cycles! With single core CPU you didn't bother to disable interrupts to flip some bit using BSET/BCLR, though knew that interrupt may flip another bit in the same reg. You don't have the same luxury when two CPUs are simultaneously accessing the same byte...

[RadekS]

As Edward wrote CPU has priority in access. On other side XGATE works on double frequency….

The main dangerous is writing into larger variables (for example 32bit). If we don’t use semaphores we can get half variable updated by CPU and half variable updated by XGATE as result … =illegal value.

Just another tip:

Unexpected interrupt. Could you please check if you can find all interrupt routines for all routed interrupts in your software? Default ErrorHandler interrupt routine contains asm BRK; command. This command stops XGATE even in normal mode. Note: interrupt nesting still working; therefore interrupt with higher priority level (4..7) can be executed.  

[Pinhead]

I know it is difficult trying to help with a problem you have so few details on, but you both are certainly managing to help.  At least the semaphore problems are starting to become clear to me.

The way the communication is timed I shouldn't have a lot of overlap in variable access anyway.  I receive information in XGATE, set an interrupt in CPU where it is processed and stored.  Then, once I have the return string, I pass that off to XGATE.  The network is small so there shouldn't be anything coming in during that time.  I am using semaphores though.

The BRK point may be on target.  Both XGATEs (master and slave) are using an error handler interrupt that contains a BRK.  I was unable to trigger this interrupt easily, but it takes an hour or two for this to fail, so maybe I just wasn't waiting long enough.  Both processors (master and slave) seem to conk out eventually.  Can I just get rid of the BRK?

The thing that bugs me is that I am also using the COP timer on both units, and I thought it would get me out of this with a reset.

[Pinhead]

There is another thing that is concerning me.  There is one interrupt vector, the reset vector, that I was forced to delete to get the whole thing to compile.

So the last two vectors were for the COP reset and just "reset".

        org     $FFFA   ;cop reset vector

        fdb      start

;;;     org     $FFFE   ;Reset - had to remove when XGATE was added to program - never figured out why

;;;     fdb     start

[kef]

It is not clear why you had to remove that vector. Did linker complain about overlapping data? Maybe reset vector was defined in PRM file or in some C file using "interrupt 0".

[RadekS]

Yes, command asm BRK; is there just for debugging purpose. You can delete this command or replace by asm NOP; instruction (just for placement of breakpoint during debugging).

Default definition of reset vector is placed in prm file: VECTOR 0 _Startup

When you define this reset vector in other file, you have to comment out this line in prm file.

Anyway I would like strongly recommend define all three reset vector (POR/CM/COP at 0xFFFE, 0xFFFC and 0xFFFA address).

When you define any of these reset vectors as interrupt routine, this routine must be ended by some jump to address (RTI instruction cannot work correctly after reset). For example:

#pragma CODE_SEG NON_BANKED

interrupt 2 void COP_ISR(void)

{

//your code (Note: Be aware, stack and variables are still not initialized)

    asm jmp _Startup;       //jump to startup code

}

#pragma CODE_SEG DEFAULT

[Pinhead]

I had forgotten about the VECTOR 0 problem!  When I changed over to start using XGATE I started a new project.  In my old project, I had that commented out, but that was several years ago and it slipped out of my mind.  So I have done that and taken your advice on the vectors.

So when I deleted the brk command that did not solve the problem.  Same thing - after about two hours, the code locked up.  As far as I can tell it is impossible for me to tell where the code stopped working.  In the debug window, everything just flies off into space.  The same thing apparently happens when not in debug mode, but it is even more difficult to tell what happened in that case.

I have attached what my vectors in the CPU and XGATE look like now.  I'll run this test now.

My problem isn't solved yet, but your advice has been very helpful.

[HSW]

Hello Chris,

Just one more thought: In case you are using one of the earlier S12X devices (Part IDs: 0xC410 and 0xC411) you need to consider erratum MUCts02988 (XGATE: Carry-Flag may be falsely set by SSEM instruction).

If this was the problem, it would explain why the application stops after such a long runtime.

Anyway, this erratum has a very simple workaround: just execute the SSEM instruction twice.