Hello everyone!
I am working on a project in Keil uVision 4 using a custom 8051W ASIC (8K in size) and found an issue when working with the large code rom size.
We were originally working with the compact model but found some of our functions at the time were over 2K so we had switched to the large model, which allowed for larger functions. Since then, we've optimized the code a lot and the functions have been all under 2K in size. We did have some issues with the startup of the chip though and, after lots of tests, determined the root cause to be because of this large model.
Keil describes the difference shown below (taken from: http://www.keil.com/support/man/docs/c51/c51_rom.htm)
Compact - CALL instructions are coded as LCALL. JMP instructions are coded as AJMP within a function. The size of a function must not exceed 2 KBytes. The entire program may, however, comprise a maximum of 64 KBytes. The type of application determines whether or not ROM (COMPACT) is more advantageous than ROM (LARGE). Any code space saving advantages in using ROM (COMPACT) must be empirically determined.
Large - CALL and JMP instructions are coded as LCALL and LJMP. This allows you to use the entire address space without any restrictions. Program size is limited to 64 KBytes. Function size is also limited to 64 KBytes.
Looking at the above description, I can see that the 2K function limit is a clear difference between the two but also that the large code rom uses LJMP rather than AJMP, which I would assume would make using the large code rom size advantageous in that respect, though this would take up more code space as a result (since the addressing is longer due to the LJMP).
However, when I use the large code rom size, I'm having issues with startup (ie the chip is unable to write to our ESFR registers at -40 degC). I'm having trouble seeing any unintentional consequences of selecting the large code rom but clearly, something is at work as it works fine using the compact code so I thought I'd come to the experts!
Can anyone shed any light on what could potentially be causing these issues? Any help would be appreciated. Thanks!
If you have any insight as to what might be going on, I'd appreciate it.
How do you expext informed insight, based on
the chip is unable to write to our ESFR registers at -40 degC
happening somehwere "in the startup code", as the entire description of the actual problem?
The same code, just built with ROM(LARGE), will be altogether bigger, so it will use more ROM, more RAM (for stack) and the C runtime startup may take a bit longer. How any of those changes would affect writing your ESFR is for someone to decide who know whichs ESFRs you're talking about, in which part of the code, and what the hardware looks like. Right now, that means you have to solve this yourself.
The same code, just built with ROM(LARGE), will be altogether bigger, so it will use more ROM, more RAM (for stack) and the C runtime startup may take a bit longer.
That right there was exactly what I was looking for but you spent your more time trying to tell me I have no idea what I'm talking about rather than just asking a question if you needed more clarification.
Honestly, you guys have a lot of good information but you guys are so rude to the people that come here for help. My original post politely showed that I knew that I was doing something wrong (as well as what I changed to fix it), came in here with the intent of understanding the problem, not just "get it working", showed I had done my research, and all I asked was for a little insight from people who know better than I would. Why do you guys insist on being aggressively unhelpful and flat out rude?
ehy just compact and large, have you tried small?