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
Have you tried asking Nordic, as it's their code & Project that we're talking about?
Are you using the Keil free evaluation?
I have tried to contact Nordic directly and also my supplier. Neither have responded to me as yet. I contacted Nordic for the first time approximately a week ago now, I have sent another email to them recently.
While I understand that the code is "Nordic's", I've also been unable to get a nrf24E1 project working from scratch, which would fall into Keils domain? Correct me if I am incorrect in this regard?
As I understand it Keil provides a compiler with support for the nrf24E1, I am able to write asm software for the nrf24E1 so it is not a hardware issue I am having as such?...? I am having trouble geting Keil to work, not the hardware...
Does Keil have a relationship with Nordic? Nordic appears to write (or at least test) its C software with Keil...
It would be nice if Nordic did have better development support! Of this I would be most helpful. :)
I understand that many people had had great success with Keil (Nordic themselves), help from those willing would be most appreciated.
Once again I apologise for my difficulties in regard to this and thank you for your help!
I am using the free evaluation.
07FDH?...(disassembling the hex files provides the same information...)
I think you want to consider your documentation or this web site about the difference betweeen an eval version and the real toolkit.
My problem has been solved,
As I suspect the error was completely mine! :)
During my attempts to get it functioning I had in the past used the Nordic program eeprep.exe to add the eeprom header, recently I had gone away from that thinking that the error was somehow the in the organisation of the code (incorrect! The offset has no effect <duh>). Using eeprep.exe again solved my problems (why this didn't work in the frist place is a ?, again without a doubt simply my fault however).
As Hans-Bernhard Broeker says I think it would help if Keil said that the evaluation version added an offset ***GAP*** to the code (why I am not sure? I was under the understanding it was simply code limited...).
Thanks again for your help! (and apologies again for my lack of brains :) )
...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