MSefi.com read only forum (Jan.15,2018)

Ok, I gave up on gcc (for now) and went the CodeWarrior route even though I haven't used it in > 10 years. I got the 2.890 code to compile and come in under the code size limit by ifdef'ing out lots of stuff. My problem is I can't modify the inpram fields using MegaTune, and I just wanted to verify that reading and writing the inpram fields is relative to the inpram base address. When I power it on flashes the fuel pump and the RPM swings like it should, and the ECU type is showing as 255 in MegaTune. Since the RPM swings between 0 and 8000 so I'm pretty sure that reading outpc is working fine. When I change the ECU type to 1, burn it, and then fetch it back it is still 255. When I try to download an entire MSQ it fails and serial communication ceases until I reboot. I'm pretty sure I'm overwriting something I shouldn't be and I'm wondering if the inparms base address changed when I modified the file even though I didn't get rid of any variables. I did end up with a lot of unused variables that perhaps the compiler optimized away. Thanks

I just noticed it generated a warning "pragma ROM_VAR was not handled" for the line "#pragma ROM_VAR DEFAULT" before the table* macros are #define'd on about line 1450. Perhaps that's my problem, but I don't know what it means.

steamer wrote:I just noticed it generated a warning "pragma ROM_VAR was not handled" for the line "#pragma ROM_VAR DEFAULT" before the table* macros are #define'd on about line 1450. Perhaps that's my problem, but I don't know what it means.

Ignore the "pragma ROM_VAR was not handled" message - I got rid of that in going to the 3.x code and using the correct CODE_SEG and DATA_SEG pragmas, but the message is harmless at least it has been for me for dozens of code versions and enormous code changes. The HCS12 memory structure is a nightmare because its Paged memory is a kluge and because it is very poorly documented.

The inpram base address isn't 'absolute' and if it changed the compiler would take care of this. It's one reason for using a structure for this purpose.

Yoou do have to make sure you don't go over 1024 bytes total in inpram (or in2ram), and that the INI corresponds exactly to the inpram structure in both sequence, offset and type. Typos here are the most common cause I have experienced of what you see.

What I meant to ask was whether or not the absolute address was encoded in the INI file somehow. I think the answer is 'no' and the communication protocol uses offsets from the base to refer to inpram fields. I didn't change anything in inpram so the existing INI should work.

I was able to get further setting the default ECU to '1' and reflashing. Now it allows me to set and read variables -- I suspect reflashing solved my earlier problem and not changing the default ECU setting. I find I have to reflash too many times (once is too many), I'm not sure why it is so fragile. Now the TPS and MAP work when connected to the stimulator but there is no RPM signal. I'm guessing I commented out a little too much code.

grippo wrote:The HCS12 memory structure is a nightmare because its Paged memory is a kluge and because it is very poorly documented.

Glad it's not just me. For general information, I found the following Motorola app note (AN2216/D) which explains it relatively well:
http://www.datasheetarchive.com/AN2216-datasheet.html

Otoh, that is in the context of a 256kB flash chip. I still don't understand what is the advantage of using paged memory in a 64kB
chip, given that in principle all the memory is directly accessible via a 16 bit address. That would seem to happen if you select the
"small" memory model in the compiler, I think?

Am I wrong about that, or was the paged model used to provide an upgrade path to a chip with >64k flash?

Oops, Ok... of course there is the 64K of Flash, but also the 4K of RAM and the EEPROM. Soooo if I use -Ms then I can't access
all of the flash.

Otoh, using the free version of CW it makes no difference to me, since I can only generate 32K of code. So even if I use the banked model,
I might as well just leave the PPAGE fixed to 3C or 3D since that gives me 48K (less 256B for vector storage) together with the two always visible
pages 3E & 3F....