| View previous topic :: View next topic |
| Author |
Message |
richi-d
Joined: 28 Aug 2007
Posts: 106
|
| No return on the program end |
 Posted: Sat May 05, 2012 3:01 am |
 |
|
Hello,
I have a problem: with this code there is no return on the end of my code, so at a point of my program, the software is standing. This is just the start. There are a mass of subroutines and so on...
| Code: |
#include <24FJ192GA108.h>
#device adc=10
#device *=16
#BUILD (interrupt=0x408) //In diesem Bereich sind jetzt die Pointer für die Interrupts
//IVT Mapping to application code space
#ROM 0x04 = {0x04 *2 + 0x0400}
#ROM 0x05 = {0x00}
#ROM 0x06 = {0x06 *2 + 0x0400}
#ROM 0x07 = {0x00}
#ROM 0x08 = {0x08 *2 + 0x0400}
#ROM 0x09 = {0x00}
#ROM 0x0A = {0x0A *2 + 0x0400}
#ROM 0x0B = {0x00}
#ROM 0x0C = {0x0C *2 + 0x0400}
#ROM 0x0D = {0x00}
#ROM 0x0E = {0x0E *2 + 0x0400}
#ROM 0x0F = {0x00}
#ROM 0x10 = {0x10 *2 + 0x0400}
#ROM 0x11 = {0x00}
#ROM 0x12 = {0x12 *2 + 0x0400}
#ROM 0x13 = {0x00}
#ROM 0x2E = {0x2E *2 + 0x0400}
#ROM 0x2F = {0x00}
#ROM 0x38 = {0x38 *2 + 0x0400}
#ROM 0x39 = {0x00}
#ROM 0x9A = {0x9A *2 + 0x0400}
#ROM 0x9B = {0x00}
#ROM 0xAE = {0xAE *2 + 0x0400}
#ROM 0xAF = {0x00}
#ROM 0x14 = {0x14 *2 + 0x0400}
#ROM 0x15 = {0x00}
#ROM 0x3C = {0x3C *2 + 0x0400}
#ROM 0x3D = {0x00}
#ROM 0x4E = {0x4E *2 + 0x0400}
#ROM 0x4F = {0x00}
#ROM 0x7E = {0x7E *2 + 0x0400}
#ROM 0x7F = {0x00}
#ROM 0x80 = {0x80 *2 + 0x0400}
#ROM 0x81 = {0x00}
#ROM 0x36 = {0x36 *2 + 0x0400}
#ROM 0x37 = {0x00}
#ROM 0x34 = {0x34 *2 + 0x0400}
#ROM 0x35 = {0x00}
#ROM 0x78 = {0x78 *2 + 0x0400}
#ROM 0x79 = {0x00}
#ROM 0x76 = {0x76 *2 + 0x0400}
#ROM 0x77 = {0x00}
#ROM 0xBE = {0xBE *2 + 0x0400}
#ROM 0xBF = {0x00}
#ROM 0xBC = {0xBC *2 + 0x0400}
#ROM 0xBD = {0x00}
#ROM 0x16 = {0x16 *2 + 0x0400}
#ROM 0x17 = {0x00}
#ROM 0x1E = {0x1E *2 + 0x0400}
#ROM 0x1F = {0x00}
#ROM 0x5E = {0x5E *2 + 0x0400}
#ROM 0x5F = {0x00}
#ROM 0x60 = {0x60 *2 + 0x0400}
#ROM 0x61 = {0x00}
#ROM 0x62 = {0x62 *2 + 0x0400}
#ROM 0x63 = {0x00}
#ROM 0x64 = {0x64 *2 + 0x0400}
#ROM 0x65 = {0x00}
#ROM 0x40 = {0x40 *2 + 0x0400}
#ROM 0x41 = {0x00}
#ROM 0x42 = {0x42 *2 + 0x0400}
#ROM 0x43 = {0x00}
#ROM 0xCE = {0xCE *2 + 0x0400}
#ROM 0xCF = {0x00}
#ROM 0x3A = {0x3A *2 + 0x0400}
#ROM 0x3B = {0x00}
#ROM 0xA4 = {0xA4 *2 + 0x0400}
#ROM 0xA5 = {0x00}
#ROM 0x18 = {0x18 *2 + 0x0400}
#ROM 0x19 = {0x00}
#ROM 0x20 = {0x20 *2 + 0x0400}
#ROM 0x21 = {0x00}
#ROM 0x46 = {0x46 *2 + 0x0400}
#ROM 0x47 = {0x00}
#ROM 0x48 = {0x48 *2 + 0x0400}
#ROM 0x49 = {0x00}
#ROM 0x66 = {0x66 *2 + 0x0400}
#ROM 0x67 = {0x00}
#ROM 0x68 = {0x68 *2 + 0x0400}
#ROM 0x69 = {0x00}
#ROM 0x6A = {0x6A *2 + 0x0400}
#ROM 0x6B = {0x00}
#ROM 0x6C = {0x6C *2 + 0x0400}
#ROM 0x6D = {0x00}
#ROM 0xCC = {0xCC *2 + 0x0400}
#ROM 0xCD = {0x00}
#ROM 0x6E = {0x6E *2 + 0x0400}
#ROM 0x6F = {0x00}
#ROM 0x90 = {0x90 *2 + 0x0400}
#ROM 0x91 = {0x00}
#ROM 0x26 = {0x26 *2 + 0x0400}
#ROM 0x27 = {0x00}
#ROM 0x28 = {0x28 *2 + 0x0400}
#ROM 0x29 = {0x00}
#ROM 0x54 = {0x54 *2 + 0x0400}
#ROM 0x55 = {0x00}
#ROM 0x56 = {0x56 *2 + 0x0400}
#ROM 0x57 = {0x00}
#ROM 0xC8 = {0xC8 *2 + 0x0400}
#ROM 0xC9 = {0x00}
#ROM 0xCA = {0xCA *2 + 0x0400}
#ROM 0xCB = {0x00}
#ROM 0x1A = {0x1A *2 + 0x0400}
#ROM 0x1B = {0x00}
#ROM 0x22 = {0x22 *2 + 0x0400}
#ROM 0x23 = {0x00}
#ROM 0x24 = {0x24 *2 + 0x0400}
#ROM 0x25 = {0x00}
#ROM 0x4A = {0x4A *2 + 0x0400}
#ROM 0x4B = {0x00}
#ROM 0x4C = {0x4C *2 + 0x0400}
#ROM 0x4D = {0x00}
#ROM 0x96 = {0x96 *2 + 0x0400}
#ROM 0x97 = {0x00}
#ROM 0x2A = {0x2A *2 + 0x0400}
#ROM 0x2B = {0x00}
#ROM 0x2C = {0x2C *2 + 0x0400}
#ROM 0x2D = {0x00}
#ROM 0x98 = {0x98 *2 + 0x0400}
#ROM 0x99 = {0x00}
#ROM 0x50 = {0x50 *2 + 0x0400}
#ROM 0x51 = {0x00}
#ROM 0x52 = {0x52 *2 + 0x0400}
#ROM 0x53 = {0x00}
#ROM 0xB6 = {0xB6 *2 + 0x0400}
#ROM 0xB7 = {0x00}
#ROM 0xB8 = {0xB8 *2 + 0x0400}
#ROM 0xB9 = {0x00}
#ROM 0xBA = {0xBA *2 + 0x0400}
#ROM 0xBB = {0x00}
#ROM 0xC2 = {0xC2 *2 + 0x0400}
#ROM 0xC3 = {0x00}
#ROM 0xC4 = {0xC4 *2 + 0x0400}
#ROM 0xC5 = {0x00}
#ROM 0xC6 = {0xC6 *2 + 0x0400}
#ROM 0xC7 = {0x00}
#ORG 0x0D0,0x03FE {} //Hier sind die Hardware IVT´s darf nicht überschrieben werden.
#include <Main.h>
#include "Display_Steuerung.h"
#include "Display_Steuerung.c"
#include "Steuerung.h"
#include "Steuerung.c"
#include "Init.h"
#include "Init.c"
#include "SPI_EEPROM.h"
#include "SPI_EEPROM.c"
#include "Zeichensatz.h"
#include "Zeichensatz.c"
#include "IIC.h"
#include "IIC.c"
#include "Testprogramm.h"
#include "Testprogramm.c"
#include "Interrupts.h"
#include "Interrupts.c"
//#build (reset=0x800) //Bleibt fix- nicht ändern wg. Bootloader Einsprung, Löschen für Standalone Programm
#ORG 0x0804,0x0AFFE
void main()
{
CLKDIV = 0x0000;
OSCTUN = 0;
....
} |
When I remove this:
| Code: | #ORG 0x0804,0x0AFFE
|
All is working...
what can be the fault? I need that lines and definitions for the bootloader, which is an external program. The interesting is: I modified the code only a little bit- before this change I also had no problem. The compiler version is 4.132 |
|
 |
jeremiah
Joined: 20 Jul 2010
Posts: 1349
|
|
| Posted: Sat May 05, 2012 1:46 pm |
|
|
Well you are doing some very odd things. From your comments, this doesn't look like it is supposed to be bootloader code, yet you are leaving bootloader code in. The #ROM lines should all be done by the bootloader, not the applicaiton. At the top of your application, you should only need:
| Code: |
#build (reset=app_reset)
#build (interrupt=0x0408)
#org 0x0000,0x3FF {} //keep code out of the hardware IVT
|
+ a #org {} for any other bootloader locations if any more exist.
Where you specify the app_reset parameter (not sure if you want it at 0x800 or 0x804 since you have conflicting values typed out in your code). I would have expected 0x400 though given your IVT setup though. What address does your bootloader expect the main to be in?
With that setup, the compiler automatically links main to the value you specify at app_reset, so you don't need the #ORG for main. |
|
|
richi-d
Joined: 28 Aug 2007
Posts: 106
|
|
| Posted: Mon May 07, 2012 3:34 am |
|
|
Hi,
the bootloader expects the reset at 0x800. The bootloader is another program writen with Microchip compiler. What I hate is, that I write Code- all is working. Some weeks later, I change only 1 line in the code and I sitting here for 5 days trying to get the program running, because the compiler makes things no one knows why.
Does CCS think this is a professional work?
I expect that a person from CCS contacts me and helps me fixing this bugs!! |
|
|
richi-d
Joined: 28 Aug 2007
Posts: 106
|
|
| Posted: Mon May 07, 2012 3:38 am |
|
|
Additional to that: the application is running without this #rom lines. With the #rom lines the application is running only half. I see the interrupts are working, but for example my OLED screen is black. Debbugging that shows me that the code is stepping. But it´s not working when I press run.
Tell me: how should I work with such a tool? |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Mon May 07, 2012 4:12 am |
|
|
I just posted a comment in your other thread and now I see you are active here as well. | richi-d wrote: | Does CCS think this is a professional work?
I expect that a person from CCS contacts me and helps me fixing this bugs!! |
I was going to post a witty comment but now I decided otherwise and go and spent my time somewhere more productive.
O yes, please read the text at the top right of this forum: 'CCS does not monitor this forum on a regular basis.'
This is a user's forum. For CCS support you have to send them an email at the provided address. |
|
|
richi-d
Joined: 28 Aug 2007
Posts: 106
|
|
| Posted: Mon May 07, 2012 4:15 am |
|
|
If you are looking 5 days for an error which is not your fault and spending a whole weekend with this. And you have still not found out what´s the problem, you would be also very angry.
Now I found out that it depends to the order you are writing the #roms...
This order works:
| Code: | #ROM 0x04 = {0x04 *2 + 0x0400}
#ROM 0x06 = {0x06 *2 + 0x0400}
#ROM 0x07 = {0x00}
#ROM 0x05 = {0x00}
#ROM 0x08 = {0x08 *2 + 0x0400}
#ROM 0x0B = {0x00}
#ROM 0x0A = {0x0A *2 + 0x0400}
#ROM 0x09 = {0x00}
#ROM 0x0F = {0x00}
#ROM 0x0E = {0x0E *2 + 0x0400}
#ROM 0x0D = {0x00}
#ROM 0x0C = {0x0C *2 + 0x0400}
#ROM 0x10 = {0x10 *2 + 0x0400}
#ROM 0x11 = {0x00}
#ROM 0x12 = {0x12 *2 + 0x0400}
#ROM 0x14 = {0x14 *2 + 0x0400} |
this order doesn´t work:
| Code: | #ROM 0x04 = {0x04 *2 + 0x0400}
#ROM 0x05 = {0x00}
#ROM 0x06 = {0x06 *2 + 0x0400}
#ROM 0x07 = {0x00}
#ROM 0x08 = {0x08 *2 + 0x0400}
#ROM 0x09 = {0x00}
#ROM 0x0A = {0x0A *2 + 0x0400}
#ROM 0x0B = {0x00}
#ROM 0x0C = {0x0C *2 + 0x0400}
#ROM 0x0D = {0x00}
#ROM 0x0E = {0x0E *2 + 0x0400}
#ROM 0x0F = {0x00}
#ROM 0x10 = {0x10 *2 + 0x0400}
#ROM 0x11 = {0x00}
#ROM 0x12 = {0x12 *2 + 0x0400}
#ROM 0x13 = {0x00}
#ROM 0x2E = {0x2E *2 + 0x0400}
#ROM 0x2F = {0x00} |
But I can´t see any pattern....
Any ideas? |
|
|
richi-d
Joined: 28 Aug 2007
Posts: 106
|
|
| Posted: Mon May 07, 2012 5:04 am |
|
|
I found out: this is a compiler version problem with 4.132. With Version 4.121 the #Roms are written correct, but this:
| Code: |
#ROM 0x00 = {0x040800}
#ROM 0x01 = {0x000000} |
is not writen with the 4.121 version... So I have 2 versions and not one is doing correct code? |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Mon May 07, 2012 5:29 am |
|
|
I do understand that looking for the cause of a bug can be very frustrating. All of us have been there. More than once too.
Instead of random changes to your program try to attack it like a research problem. Think about smart ways to find the cause of your problem.
1) First of all make your program as small as possible by removing all code that is not related to the error. Continue until the program is less than 50 lines, even less when possible. This will help you focus on the problem and makes it possible to post the whole program in this forum.Often to me it happens that in this process I discover the problem cause.
2) Don't guess about what is wrong but measure! Tools available to you are:
- the list file with generated assembly code (*.lst)
- Debugger tools like the Microchip ICD3 which allow you to single step through a program and examine memory areas.
- If you can't debug code on the real target then the simulator in the free MPLAB suite has proved to be very helpful.
- Add lots of printf-statements and/or debug breakpoints to your code so you can follow the real program flow instead of how you _assume_ the program is executing.
3) Use external resources. You already found this forum but you could also try CCS. No guarantee they will help, but sometimes they do. To improve your chances you should make it easy for CCS to reproduce your problem, see tip 1 again.
As for me, I still have no clue as to what your actual problem is.
What is working, and when it is not working what do you see?
You post a long list of #org statements, what are these supposed to do?
The program as posted is to be used with a bootloader. Does it work without bootloader?
etc. |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Mon May 07, 2012 5:32 am |
|
|
| richi-d wrote: | I found out: this is a compiler version problem with 4.132. With Version 4.121 the #Roms are written correct, but this:
| Code: |
#ROM 0x00 = {0x040800}
#ROM 0x01 = {0x000000} |
is not writen with the 4.121 version... So I have 2 versions and not one is doing correct code? |
When you say the values are not written, how did you test this?
Are the values not in the PIC?
Are the values in the generated hex file? |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
|
richi-d
Joined: 28 Aug 2007
Posts: 106
|
|
| Posted: Mon May 07, 2012 6:10 am |
|
|
I see that this values are wrong in the Program memory. I have a real ICE and know how to debug. But debugging is not the problem.
- The compiler version 4.121 doesn´t write the #ROM to adress 0 and 1 but all other #rom statements are correct in the program memory
- The compiler version 4.132 writes adress 0 and 1 correct and some other #rom adresses, but not all #roms are correct.
I need this #rom statements to bring the IVT´s to a higher place as 0x400 because PIC24FJ have a hardware issue in the REV01. You cannot write with the bootloader to adresses lower than 0x200 if Code Protect is enabled.
So I need to make my code for PIC Rev01 and the newer one also... with the #rom table it was o.k. But I made a lite change to code last week and found that the compiler (4.105) now has a problem- I didn´t change anything in the table. Also bootloader was the same. I found in the program memory that after a subroutine the compiler make no return. So I switched to the newer version...and the things began to get harder!
I hope you can see my trouble- we sold hundred of PIC with Rev01 and we always have to look for compatibility.
Last edited by richi-d on Mon May 07, 2012 6:23 am; edited 1 time in total |
|
|
richi-d
Joined: 28 Aug 2007
Posts: 106
|
|
| Posted: Mon May 07, 2012 6:23 am |
|
|
| #rom int16 works now- oh man- how can I know that? |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1349
|
|
| Posted: Mon May 07, 2012 9:31 am |
|
|
| richi-d wrote: |
I need this #rom statements to bring the IVT´s to a higher place as 0x400 because PIC24FJ have a hardware issue in the REV01. You cannot write with the bootloader to adresses lower than 0x200 if Code Protect is enabled. |
Those #ROMs are all below 0x0200. How do you expect your bootloader to write them if it can't write lower than 0x200? If the bootloader already has those values in it at those addresses, then you don't even need the #ROMs in your application. |
|
|
richi-d
Joined: 28 Aug 2007
Posts: 106
|
|
| Posted: Sat May 12, 2012 3:32 am |
|
|
Hi,
I need that in case of an older software version on newer PICs being updated. In previous versions we didn´t write the IVT´s, but the IVT´s are below 0x200. With this table in the newer software the are linked to higher than 0x400. |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1349
|
|
| Posted: Sat May 12, 2012 6:45 am |
|
|
Yes, but I am asking how that actually works. You said that it couldn't write below 0x200. Those ROM statements are below 0x200. How does that work?
I get that you have older version where the linkage is necessary, I am just asking how it works since you said you can't write to 0x000-0x200 anyways. It doesn't make sense. Is the older version able to write to 0x000-0x200 and the newer version not? If so, does the newer version ignore those #ROM statements or does it toss up an error when it gets the ROM hex file that says to write to those locations?
Assuming the new bootloader ignores them and the old bootloader writes them, then the old bootloader's reset vector is gonna be clobbered most likely, since a page erase will be done, which means all the bootloader code in 0x0000-0x03FF will be erased, the IVT mapping will be written in and the reset vector will point to your application main....based on the code you have provided so far. Is that the way you want the old bootloader to work? You won't be able to run the bootloader again in that scenario.
I bolded the questions I am interested in since I tend to ramble sometimes |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
