RCM 6700 UserBlockArray rewrites first wariable.

Rabbit Rabbit Software
, ,
1

Hi all,

I have encounterd a problem using userblockarray on RCM6700. When I turn down the rabbit and power it up again, the first variable of the userblock (despite its type word, int, long, struct) is set to 0xFF.

Thought it was due to some array that went out of its limit, i double checked it and it’s not the problem.
Any sugestions?

PD. I’ve tried the sample code, and there are no issues with the flash.

Thanks.

2

Can you share the code you’re using to read and write the userblock? Is one of the sample programs exhibiting the error such that I could test it on my hardware?

3

No, the sample program does not exhibit same error, it works fine.
I’m using BBram and userblock simultaneously, could this produce some issues?

I’ve double checked if there were any array or variable that was written out of it’s max size.

void* save_data[4];

unsigned int save_lens[4];

longword SCADA_IP[3];

int SCADA_port;

char numero_magico[10];

struct{

char zona;

char zona2

char direccion

}OCR[MAX_OCR];

//WRITE

strcpy(numero_magico,CTE_MAGICA);

save_data[0] = &SCADA_IP;

save_lens[0] = sizeof(SCADA_IP);

save_data[1] = &SCADA_port;

save_lens[1] = sizeof(SCADA_port);

save_data[2] = &numero_magico;

save_lens[2] = sizeof(numero_magico);

save_data[3] = &OCR;

save_lens[3] = sizeof(OCR);

status=writeUserBlockArray(0, save_data, save_lens, 4);

//READ

save_data[0] = &SCADA_IP;

save_lens[0] = sizeof(SCADA_IP);

save_data[1] = &SCADA_port;

save_lens[1] = sizeof(SCADA_port);

save_data[2] = &numero_magico;

save_lens[2] = sizeof(numero_magico);

save_data[3] = &OCR;

save_lens[3] = sizeof(OCR);

readUserBlockArray(save_data, save_lens, 4, 0);

void rechecksum_values(void)

{

int i;

logs._crc = getcrc((char*)&logs + sizeof(logs._crc),sizeof(logs)-sizeof(logs._crc),0 );

for(i=0; i

Thank you in advance,
Konstantin

4

Using the debugger, can you confirm that SCADA_IP[0] is correct immediately before writing it to the userblock, and then check it again immediately after calling readUserBlockArray()?

5

Yes, i’ve checked it, and the data is alright.

Found out that if I try reading the data several times, it eventually reads ok… How ever, the readuserblock function returns “0” all the times.

6

Is it possible you’re doing something in another task/costate while trying to do the read? Any other hardware sharing those I/O lines (PB0, PB4-6)? It should always read correctly.

7

Hi,
No, there is no hardware using those pins.

It would seem that the problem is solved now, I need to run some more tests to confirm this.

I have recompiled the BIOS and rewriten the ID block.

Thanks,
Konstantin

8

Hello again,

After some testing, i found out that the issue isn’t solved.

I’ll continue looking into it…

9

Hi Tom,

Unfortunately, I have one more problem with userblock. This time it’s related to “writeUserblockArray”, the status is 0 (OK) as always, but it writes nothing.
If you try to read inmediatelly after writing, you see only 0xFF everywhere.
This time I do use the port B pins. Any sugestions? I’ve tried reconfigurig port B to default before writing, does nothing.

WrPortI(PBDDR,&PBDDRShadow,0xC0);
#ifndef DC_RABBIT_DEBUG
WrPortI(PCDDR,&PCDDRShadow,0x51);
#endif
//WrPortI(PDDDR,&PDDDRShadow,0xFF);
WrPortI(PEDDR,&PEDDRShadow,0xFF);

// Parallel port C, D and E output type configuration (0-Driven high/low 1-Open drain)
WrPortI(PCDCR,&PCDCRShadow,0x00);
//WrPortI(PDDCR,&PDDCRShadow,0x00);
WrPortI(PEDCR,&PEDCRShadow,0x00);

// Parallel port C, D and E alternate options output pins configuration
WrPortI(PCALR,&PCALRShadow,0x00);
#ifdef DC_RABBIT_DEBUG
port_value = RdPortI(PCAHR); // Pins 6 and 7 are left unchanged so Rabbit debugging is available
port_value = port_value & 0xC0;
port_value = port_value | 0x03; // Pin 4 PC4 as alternate function 3
WrPortI(PCAHR,&PCAHRShadow,port_value);
#else
WrPortI(PCAHR,&PCAHRShadow,0x03);
#endif
//WrPortI(PDALR,&PDALRShadow,0x00);
//WrPortI(PDAHR,&PDAHRShadow,0x00);
WrPortI(PEALR,&PEALRShadow,0xFF);
WrPortI(PEAHR,&PEAHRShadow,0xFF);
// Parallel port C, D and E type configuration (0-I/O 1-Alternate function)
WrPortI(PCFR,&PCFRShadow,0xFA);
//WrPortI(PDFR,&PDFRShadow,0xFF);
WrPortI(PEFR,&PEFRShadow,0xFF);

Thanks a lot,
Konstantin

10

Let’s take this to email. I suspect that there are some issues with how you’re configuring your ports, and I’m surprised to see all of the hard-coded values in your WrPortI() calls. You should typically start with the shadow value and set/clear only the bits that you need to modify. If you don’t make any changed to port B (PBxxx registers), does your code work reliably? Feel free to send me code, preferably a stand-alone program I can run on the standard development board and see the problem you’re experiencing.

If you modify your program to skip the hardware initialization entirely, can you get reliable reads/writes to the userblock? If so, you can bring in initialization code in chunks until it breaks, and then you know which registers are causing your trouble.

11

For others who stumble upon this question, I was able to determine the cause after working directly with the customer. Here’s the result of that conversation:

The default for HDLCopenE() has it using PD6, which will conflict with using it to read/write the serial boot flash.

You can change the pins used for HDLC with this macro:

#ifndef HDLC_E_USEPORT
#warnt “Define HDLC_E_USEPORT to C, D or E. Defaulting to D.”
#define HDLC_E_USEPORT D
#endif

Based on what you wrote below, it sounds like you just need to have

#define HDLC_E_USEPORT E

In your program before you #use that library. With the current configuration, it’s using PD6 for TXe (referred to as HDLC_E_MUX in the code).

1 Like