Hi Vincent

Thanks.

1) I have RIDE7 IDE 7.16.0000 (I don't need peripheral simulation, just basic initialisation checking)

2) OK. It is however a shame that there is not an easy method to select other output formats as most IDEs do have (maybe something for the "to do" list?).

3) I looked but just couldn't see it --- sorry.

Regards

Mark

Hi,

1)
Your Ride is quite old. You really should update it.
Be careful to update both the Ride7 and RKit-ARM kits. (and any other kit you might have installed)

2)
Our debuggers and programmers handle hex and elf. All the rest we give or distribute for free, in the ARM toolchain.
It's a shame but we must focus on things that we sell, (programmer, debugger)
or that might help us sell other things. (IDE, project manager)
Does your boss pay you for making things he gives away?

Using other formats is always for using other programmers or debuggers than ours, so when using them in any case you need to have some programming process outside of Ride. You can just include the call to objcopy in this external process. In fact it's a shame your other programmer doesn't handle hex format, like all decent programmers do. ;)

Best Regards,

Vincent

Hi Vincent

I updated to a new RLink a few weeks ago and used the CD which was delivered with it. I will update from the web site to get a newer version.

The SREC/binary output has nothing to do with programmer but is a project requirement. The project requires SREC for field updates (using a serial loader embedded in the 32k bank) to allow new code to be loaded locally via UART. It has to be SREC for compatibility reasons.
The binary format is required due to encrypted Ethernet uploads via Internet (loader also in the 32k bank) where the encryption requires a binary input.

Therefore these are typical project requirements and not programmer related. I will try to add a post-build step which allows objcpy to be called.

Regards

Mark

Hi,

Be careful with the CDs in the boxes, as the distributors can keep them in stock for many months, and the CDs are often obsolete by the time you get them. Always check our website for updates.

Of course there are situations that require other formats, like those you describe, but they concern quite few customers and we have a lot of more urgent requests to handle before that. Especially considering that thanks to objcopy, this is not a critical issue but simply comfort. I mean it does not stop your project. At worst it delays it a little.

Best Regards,

Vincent

Hi Vincent

After the upgrade the project no longer links:
c:/program files/raisonance/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/bin/ld.exe: cannot find std_sbrk.lib

I need to find out why this is (and solve it of course) before I can verify that the simulator etc. works correctly.
Supposedly it is due to a newer GCC used (?)

Any ideas?

Regards

Mark

PS. I tried searching the forum but never get any hits ("Your search returned no hits. ") This seems to be the case whatever I search for(??)

Hi,

This file is a new library that we added in the latest version. It allows to prevent mixes between sprintf, malloc, etc. that were sometimes happening with the previous versions.

Please check that you have this file:
\lib\ARM\std_sbrk.lib

If not, then try to uninstall all the kits, remove the Ride folder, and install the kits again. If that still doesn't solve the problem, I will send you the file. Or you can recompile it yourself using this project: \lib\ARM\std_sbrk\std_sbrk.rprj

If you have the file, please try to compile one of the examples from Ride. (\examples\ARM\REva\ADC_STR9)
If that succeeds, check that your project includes either "\lib\ARM" in the libraries directories, or "$(RKitLib)\ARM". If the reference has been made absolute in your project and you reinstalled Ride in a different folder, that might explain the problem. If that still doesn't solve the problem, send me the .elf.ld file that is in the same folder as your project's .elf file. If the example fails to compile, send me the ADC_STR9.elf.ld file that is in the example's folder.

Best Regards,

Vincent

Hi Vincent

Thanks; adding $(RKitLib)\ARM to the library directory enables the project to link.

Regards

Mark

Hi Vincent

Unfortunately I still have the problem that the header of the ELF file is being loaded to the simulator FLASH memory (newest Ride7 version being used).
This is also happening when loading to FLASH of the real target. The memory content begins with the bytes 'E''L''F' and the real start of code (vectors) seem to be at the address 0x240. The code (obviously) doesn't run.

So I tried loading the HEX file with RFlasher7. This also had errors since it loaded the code starting at the same offset 0x240 (the target FLASH has 0xffffffff, 0xfffffff.... up to 0x240 where the code started). The HEX file also started at the address 0x240.

I tried the following:
1) converting the ELF to a HEX file using arm-none-eabi-objcopy but this resulted in the same problem of the code starting at 0x240 (suggesting the problem to be in the ELF file itself).
2) converting the ELF first to a binary and then the bin to an Intel HEX file. This gave the desired result, but the code wouldn't run.

Next I studied the code at the address 0x00000000. The original assembler was ldr PC, Reset_Addr
The hex value is 0xe59f200c. The simulator displays this as LDR R2, [PC, #+0xC] (R2 <- 5800C000H). It also puts 0x5800C000 in R2 when executed.
On the target the same happens too.
This is strange since the code doesn't match with the original assembler.

Any ideas what may be going on and how to fix the ELF?

Regards

Mark

Hi,

Please check if you have this problem with the examples from Ride. (\examples\ARM\REva\ADC_STR9)

If no, please send us (support@raisonance.com) an example project that shows the problem.

If yes, then probably you have a problem with your installation. In this case please send me the zipped example project's directory, after you have compiled it. By reading the map and listing files I should be able to understand the problem better.

Best Regards,

Vincent