Hello Stéphane,

thanks for the fast reply.

I have a Problem, I need CodeBanking because my code is more than 64k.

What can I do now?

Regards
Daniel

Daniel,

As the linker have to know the different modules before allowing you to set some of them to banks, it is mandatory to
1st link something.

I can see 2 solutions:
1. Remove some files from your project so it is smaller than 64KB. Link, set the banks, re-link and re-add the removed files.
2. Create a small project, link it. See how looks the xxx-modules.Standard.xml and create one for your project in a text
editor (may be very very long).

Regards,

Stéphane

Hi Stéphane,

I commented out some parts of the firmware to decrease the code size, but now I get the following Error:

*** ERROR C200 IN LINE 798 OF D:\Firmware\V2.2.67 Ride\source\high_level.c : maximum object size reached (8192 bytes)

Is this limitation fixed or can I change this Value?

Best regards,
Daniel

Daniel,

This error appears with the "Hobby" version which is limited up to 8 KB.

Regards,

Stéphane

Ohh,

sorry, I forgot to insert the USB-Dongle.

I have now to solve some segment & overlay problems.

Currently I have the same Project in µVision Keil and there I have a Linker-Control-File forabsolute addressing of the Segments. How can I do this with Ride?

Regards,
Daniel

Daniel,

The linker accepts response files (ie: @linker.txt)
For that, use the "LX51 Linker\Additional options\More options" field.
This file just contains linker commands (usually one per line).

For code segment relocation, see the linker documentation in the Documentation panel at
11.17 CODE (CO)

Stéphane

Hi Stéphane,

thank you for the advice, the Problem with the Linker is solved now.

I also have reduced the code size, so that the make process is running to 100%. But after that the code compressor is starting for 1 second or so and then I get the following error message:

Compressing D:\Firmware\V2.2.67 Ride\Firmware.aox
"C:\Raisonance\Ride\Bin\ccomp51_7.exe" "D:\Firmware\V2.2.67 Ride\Firmware.aox" -C -NOAOF -NOBIN -HEX LF("D:\Firmware\V2.2.67 Ride\Firmware.aox_cc.log")

Compression error: Rebuild your application
If problem persists, please contact Raisonance support

Compression complete

I tryed to rebeuild but the same error occurs. Then I want to open the Log-File: Firmware.aox_cc.log, but this file was not generated.

Can you help me?

Regards,
Daniel

Daniel,

It seems that there is a little bug in the interface between Ride7 (called CCWrapper) and CodeCompressor when passing the
log file command: it generates LF(files) whereas it must be -LF(file)

To generate the log file, cut the command (as you did for your post), but paste it to a command prompt, add the - before LF
and run it.

The log file will be generated.

If you don't understand the issue(s) and don't want to post it in this forum, you can send the log file to

Stéphane

Hi Stéphane,

ok, I have now a Log-File generated and sent it to .

I hope you can help me.

Best regards,
Daniel

Dear Stéphane,

thank you for the reply. I can tell you something about FW_INFO.

This is a normal structure in the following form:

typedef struct
{
    WORD    size;
    BYTE    ver1;
    BYTE    ver2;   
    BYTE    ver3;
    WORD    ver4;
    BYTE    crc;
    WORD fw_ean[3];
}
FW_INFO;

FYI: Datatype WORD is a 2 byte unsigned integer and BYTE is a unsigned char.

In summary this structure needs 14 bytes of codespace.

Here I have the assembler code for this segment:

FW_INFO    SEGMENT    CODE
            RSEG    FW_INFO

; Code Size
CODE_SIZE:        DW CODESIZE - 0x1010        ; code size = address of segment CODESIZE

; Firmware Version Number
fw_version:        DB    2,2,67,0,180    ; fw_version[5]

; Code CRC Byte
CODE_CRC8:        DS    1        ; reserve CRC byte

; Firmware EAN (article number)
FW_EAN:            DW 0024Ah, 0BBB7h, 07D83h    ; FW_EAN[6] = 2520000200067 (dec) <-- saved are only the first 6 bytes, this is an ULONG with 8 bytes

DS 2                                ; free space

In my firmware is the codesize, the firmware release number and the crc checksum of the whole firmwarecode fixed in this structure. In a linker command [ CODE(FW_INFO(0x1000)) ] this fixed structure is everytime mapped to the address 0x1000, but in the linker settings the code starting address is set to 0x1010 only for better reading and understanding. This means that the codespace after this structure is not used by the firmware or it seems to be undefined.

I tryed now to set the code starting address to 0x1000 because my idea was that there is an problem when I say the code has to start at 0x1010 but I tell the linker in parallel that a special segment has to be in an address space before this starting address. I rebuild the whole project again, but I get the same problem with the code compressor.

I need this fixed address, because I calculate the checksum of the firmwarecode with an external tool from me, so it would be possible to change this address, but I think the address is not the problem. I think the problem is the reservated space of 2 bytes but I can't understand that.

I sent you a new code compressor log file, wich was created after changing the code starting address.

Best regards,
Daniel

Dear Daniel,

I was able to reproduce the issue with the piece of code you provided and I found a workaroud:
instead of the DS 2 for free space use two NOP instructions and the CC will be fooled!

Stéphane

PS: on my computer, the CC wrapper used to crash in case of successful result! If it does so on yours,
I'll give you a corrected one.

Hello Stéphane,

thank you for the reply, I replaced now this reserved bytes with NOP's and the code compressor iss running to the end. It was generating a compressed hex file. But in the log file I sent to you via email, are many errors written, do I have to take care about this, or is this normal?

Yes, the cc wrapper crashes, so that I have to close it myself, but a compressed hex file was generated.

Regards,
Daniel

Dear Daniel,

Errors are never normal, but in the case, there are more warnings than real errors.
At that point. If your compressed AOF doesn't work, we'll have to check them.

A fixed CC wrapper is available at:
ftp://ftp.raisonance.com/temp/Ride7/ccw.zip

It fixes the 2 known issues (not log file and crash)

To install it, just extract the archive into your Ride\bin directory. It will overwrite the bugged wrapped.

Stéphane

Dear Stéphane,

thank you for this fixup.

It works, but now I have the next problem. My firmware is not running, neither with the compressed hex file as well as the uncompressed hex file.

It seems so that the preprocessor is doing some crazy things.

I have a very big macro file with many defines and decisions when a define has to appear or not and there are several nested decisions. Some decisions are based on mathematical calculations! I switched on in the editor options that I can see wich definitions are currently active, the inactive are gray (PS: This is a very good feature).

If this view is 100% correct, than we have here a big problem with nested definitions, because the editor shows to me not in all cases the right active decision. If it is compiling this wrong active definitions, it is not possible that the firmware will run correctly, because there are very important SYSCLK, PLL, Timer setups and so on.

Some definitions are not included in other files, even though this macro file is included, so that I have to redefine my important definitions in every seperate file. This should not be a good way to handle if the definitions are complex. And it is so that I will loose the overview, if I have to redefine all thing seperately.

Can you confirm this wrong behavior? Or do I make a mistake with the file handling and the definitions?

Best regards,
Daniel

Dear Daniel,

The engine used by the editor isn't the same as the one used by the compiler!!
Furthermore, the editor isn't aware of all defines (mainly the ones passed on the command-line).

If you're using multiple #if #else #endif, a trick to find which is used by the compiler is to use the
#error directive

#if 1
#error Compiler uses this branch
#else
// not this one!
#endif

Stéphane

Hello Stéphane,

I have checked it now with the #error directive, it seems so that all is ok.

But I can't communicate with the device. I have there an interrupt service routine for incoming data on UART0, but this routine is never called! I checked this in hardware debug mode with a breakpoint inside this function. Everytime I send a command to the device, the device will stay in the mainloop and is never interrupted.

I checked my timer configuration with a LED wich is directly connected to a controller pin. The timer is configured so that every second the LED will be switched off and on. It looks ok, so I think the timer configuration for baudrate generation should also be ok.

Interrupts are also enabled.

What should be the problem? Do I need a special project configuration to enable interrupt service routines?

Best regards,
Daniel

Daniel,

There is no need for special configuration to enable interruptions.

Does data arrive on UART0?

Stéphane

Dear Stéphane,

yes I think data will arrive on UART0, but the interrupt is not triggered even though the UART0 interrupt is enabled and therefore the interrupt service routine is not executed.

Regards,
Daniel