I am having difficulty in compiling code for the Nordic nrf24E1.
Nordic have a number of sample programs of which I am starting with ex1c.c (available from www.nordicsemi.no/.../nRF24E1_EXAMPLES_rev1_2.zip)
I am able to program (using PonyProg V2.06f and a parallel port programmer) the Nordic supplied hex file for example ex1c into my 25LC320 eeprom that the nrf24E1 uses. The program functions correctly.
I am However unable to compile my own working hex file!
The Nordic sample program supplies a uVision Project file, however when I open this file in uVision and attempt to compile the project the hex file that I able to generate does not function.
Comparing my generated hex file (does not work) to the Nordic supplied hex file (works) I see that my hex file has the data section? offest by 07FDH?...(disassembling the hex files provides the same information...)
I get the same result if I create a new project for nrf24E1 and attempt to compile that as well..
I suspect I am simply missing something in the configuration for Keil (startup.A51?, ?)....anyone that has Keil working with the nrf24E1 should I suspect be able to help me!
On the upside I have no dramas writing and programing ASM for the Nordic nrf24E1.... lol
I apologise for my difficulties with this.
William
...I think it would help if Keil said that the evaluation version added an offset ***GAP*** to the code...
I know that this limitation is written on the web site:
http://www.keil.com/demo/limits.asp
And, I am almost 100% certain that it is included in the installation program for the evaluation tools.
Jon
"...I think it would help if Keil said that the evaluation version added an offset ***GAP*** to the code..."
It looks pretty clear to me: "Programs start at offset 0x0800" http://www.keil.com/demo/limits.asp?bhcp=1
So, obviously, there will be a ***GAP*** up to address 0x0800, won't there?
(Now the location of the Reset Vector and Interrupt Vectors is fixed by the chip hardware - Keil can't change that - so they still have to be in their "normal" locations; but the rest of the code is offset to 0x0800, as stated)
Sorry I believe I posted a reply earlier apologizing once I was directed to the link that Jon Ward posted.... it doesn't appear that I actually did however...
Again, I am solely at fault here.
Thanks again for you help!
Regards William