68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC

I am flabbergasted.
Common sense tells me that hc12mem is for "HC12" devices. That would
be great because I started using the excellent combination of TBDML,
NoICE Debugger, and 68HC12.

Now I thought I might add hc12mem for production, but can only see how
to interface it with S12! NoICE proves that TBDML can properly
communicate with my MC68HC912B32.



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

P.S. Did you do anything yet to fix the previous problem with GCC and
the S8 record? I was hoping it is easy to have hc12mem consider only
the low 16 bits of the address in S8, since there is no use for the
high 8 bits anyway...
--- In 6...@yahoogroups.com, Michal Konieczny <0xmk@...> wrote:
> When I started writing hc12mem, I regarded HCS12 as ax extension of
> HC12 family, and that would be easy to support both within this
[...]

Thank you for your reply. I was guessing that may be the reason. What
I learned was that if you look at certain hardware (SPI, timers, SCI)
you see that the S12 perripherals are extentions of the HC12. But
remember, there is _no_ 'HC' in 'S12' ! What I mean is not really
related to part numbers, but the fact that in some fundamental ways
the two MCU are completely foreign from each other. Especially in
handling memory, and specifically the Flash. So for hc12mem, it will
indeed be a completely different thing to write to the two versions of
nonvolatile memory.

> It's quite easy on the current stage - most of the
> framework is ready and in place, all that is needed is some MCU
> initialization specific to HC12 family and dedicated FLASH
> programming routine.
>
> Best regards,
> --
> Michal Konieczny

I'd love to have it already done, but my HC12 product is near the end
of it's life, and it is one of those "not recommended for new design"
things. I'm actually hoping to move my employer to a more stable
technology (i.e. not going to be new this year and outdated next
year). The point of 16bit Freescale MCU has been lost. I'd recomment
something that multiple manufacturers provide, such as ARM. Of course
I realize the ARM core doesn't specify the memory, so any mem utility
would still have to adapt to the hardware specifics.



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

--- In 6...@yahoogroups.com, "Jeff Smith" wrote:
> P.S. Did you do anything yet to fix the previous problem with GCC
> and the S8 record? I was hoping it is easy to have hc12mem consider
> only the low 16 bits of the address in S8, since there is no use
> for the high 8 bits anyway...

New discovery: I was assuming that
S9034000BC
would work, but gets same error!
It is not looking for a 16-bit address. Apparently hc12mem is looking
for the same format as expected in the S2 records, and I think they
should not. Funny thing is the command doesn't even use this address,
but I made it load properly with this:
S8040F80006C
So "F8000" is what hc12mem looks for, which translates to 3E:8000 from
which 4000 is mirrored. It thinks this "entry address" should be
banked-linear notation, but that is not good because any tool using
the s-records does not necesarily have knowledge of bank switching on
startup (start vector is only 16 bits). Also, to start at PC:8000
would mess up execution.



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )