We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Yesterday I learned that my program can be 64kb big instead of just 32kb
Today I am having the problem that my program does not run when the program exceeds a certain size.
The machine I am programming does not finish it's boot cycle. And this is because timer 0 won't run. The machine at this point is stuck in a while loop, seeking connection with a HMI. Timer 0 ensures that this handshakingsprocedure runs. I've been using this handshaking for a long time on several machines without any issues.
So apparently when the program exceeds this 'limit' the timer ISR appears to be overwritten or something.
IDE-Version: µVision V5.24.2.86 Copyright (C) 2017 ARM Ltd and ARM Germany GmbH. All rights reserved.
License Information: sebastiaan knippels Holland Mechanics b.v.
Tool Version Numbers: Toolchain: C51 Compiler/Assembler Kit Version: 9.57.0.0 Toolchain Path: C:\Keil_v5\C51\BIN C Compiler: C51.exe V9.57.0.0 Assembler: A51.exe V8.2.7.0 Linker/Locator: BL51.exe V6.22.2.0 Librarian: LIB51.exe V4.30.1.0 Hex Converter: OH51.exe V2.7.0.0 CPU DLL: S8051.DLL V3.113.0.0 Dialog DLL: DP51.DLL V2.64.0.0
The device I am programming is a virtual 8051 chip which is emulated on a FPGA chip. This hardware is fine and they have been programmed in assembly with programs exceeding 32kb.
Both my Off-chip code memory as well as my off-chip Xdata memory start at 0x0000 and have a size of 0xFFFF.
I would like to know why this happened and how I can fix this in Keil uVision. It is propably a certain target setting but I cannot seem to find it.
Momentarily I have set the compiler at level 9 code optimalization which produces a slightly smaller program. This produces fine code.... so far. I expect to get the same problem when my program grows again
How do you establish that?
What stops it running?
Surely, a timer not running is a "hardware" issue?
You should be able to step your code to see where it should start - and what is or isn't happening that stops it.
Presumably, your FPGA tools give you insight into what's happening in the "hardware" ... ?
"The device I am programming is a virtual 8051 chip which is emulated on a FPGA chip"
So you're really on your own with that, then!
Nobody can have the same hardware as you to even have the possibility of trying for themselves!
You probably need to seek support from the FPGA people ...
Did you follow the suggestions in your other thread on possible ways to streamline your code?
http://www.keil.com/forum/63694/
In this size of code, using Generic Pointers could certainly be having a significant impact ...
Making optimum use of DATA, IDATA, and PDATA can also bring worthwhile savings ...
Well I drew my conclusion on this part of code which runs on start up
start_bool=0; startTimer1(handshaking,250); while(start_bool == 0) { updateTimers(); }
updateTimers() only checks if a counter reaches 0 and than executes a function. Timer 0's ISR decrements this counter. startTimer1() sets the counter at 250. Timer 0 is already set at this point and should thus decrement the counter, only this does not happen.
Using an output I could verify that the code was stuck in this while loop. Start_bool becomes true when the handshaking function is executed 2 times. And as said before it always worked before.
IIRC the ISR vector address of this timer is 0x0013. So I thought this would be one of the first things which would get overwritten were thatto actually happen.