Ok… we seem to have hit on a rather odd problem… I can’t think of any good reasons for it yet…
When we load our code into the controller, everything works as expected and life is fun… until we reset the bot. Then the programming light turns orange… it does the same thing with a power-off-power-on type of reset also… I’d say its the controller malfunctioning, but when we reload the default hex file it works like a charm, no problems. So… we’re quite lost on why is happening. We’re going to start stripping our code down until we figure out whats going on… but if anyone has any ideas we would appreciate it!
Some information:
Did NOT change the ifi_x files, started using the code that we downloaded a few days ago from IFI.
DID play around with the linker script… we needed a variable over 256 bytes, and the linker didn’t like that… so we adjusted one of the databanks to the size we needed, and eliminated one of them… then adjusted everything else around it. However, when we put back the normal linker file, and deleted the huge variable… it still didn’t work.
We are currently using:
Timer1, EEPROM stuff (using about 3/4th of the EEPROM memory available), and most of the default code is still in place. However, we do have 7 additional source files that are compiled and linked in. according to the MAP file generated, we are using about 40% of the space.
The C18 compiler that ships with the controller (v2.20 i think) that we got from IFI over the summer or in the fall I believe… However, we’re using MPLAB 7.00, and it is using the new linker that came with MPLAB instead of the old linker.
It’s something with your code. It has happened to us, because, I think we have something in a while statement in user routines.c that it did not like. Play around with your code and you’ll figure it out, hopefully…
Well… figured out what went wrong. It’s sorta obvious, but was rather stupid. We tried doing a printf() in some of our initialization code, and we had placed it before initialize_serial_comms()… so, yeah, great error…
The default code that IFI provides us works. If we modify it and break it, it can not be their fault. We must assume responsibility for our actions.
Just what is the value of an uninitialized variable? Answer: It is undefined. If you are lucky, it will be 0x0000 or 0xFFFF. If you are unlucky, it can be anything.
My point here is that it is impossible to do what you suggest in an embedded controller.
It is possible in a program running under an operating system (the operating system guarantees the starting state of RAM).
Actually, it is possible. If you assign an initial value to a static variable, the C compiler will automatically generate code to put the correct value in that location in RAM. This code is hidden from the user and is called before control is passed to the C program’s entry point (usually main()).
{edit} The code that does this is in _do_cinit() in ifi_startup.c {/edit}
{edit2} But I agree with you that if you modify the default code then it becomes your responsibility to ensure there’s no bugs. It would be impossible for IFI to protect the end users against all of the various mistakes like this that are possible. {/edit}