On Sat, Feb 27, 2010 at 1:51 PM, David Brownell <[email protected]> wrote:
> On Saturday 27 February 2010, Mariano Alvira wrote:
>> On Sat, Feb 27, 2010 at 09:00:32AM -0800, David Brownell wrote:
>> > On Thursday 25 February 2010, Mariano Alvira wrote:
>> > > ---
>> >
>> > Needs a patch comment.
>>
>> Ok. Do the subject lines not get added as patch comments? I figured
>> they would since they are generated from the commit messages.
>
> Patches need two kinds of descriptive metadata:
>
> - one-line summary ... $SUBJECT
> - patch description
>
> The $SUBJECT should make sense when for example scanning the gitweb
> summary of what changes have been made. But since it has no details,
> it's insufficient for anything except tracking broadly what changed.
> In this case, it doesn't even identify who makes the chip or why any
> OpenOCD user might care.
>
>>
>> >What's an MC13224V? Maybe:
>> >
>> > The MC13224V is a FreeScale ARM7TDMI based IEEE® 802.15.4 platform for
>> > Zigbee and similar low-power wireless applications. It uses PIP
>> > (Platform In Package) technology, and boots from ROM which shadows
>> > code from serial flash into RAM.
>>
>> Sure. Thanks.
>
> THat was my attempt at a decent description. When combined with
> the "add target/...cfg" summary, folk now have some real information.
> In particular it mentions the unusual boot scheme: the flash isn't
> "on-chip" NOR (with execute-in-place) but "in-package" serial (which
> needs to be shadowed into a relatively large SRAM).
>
> I don't entirely "get" these chips which execute code from large SRAMs
> instead of from NOR flash ... I had understood that the SRAMs use more
> power than the NOR flash, so that most microcontrollers minimized the
> quantity of SRAM they included (even at the cost of annoying the folk
> writing code that might like more SRAM).
The mc13224 has 64KB flash and 96KB RAM. The flash is attached
internally on SPI. You can not directly execute code out of it. The
ARM boot ROM looks at the SPI flash for a valid signature, if found it
will copy the 64KB flash into RAM and jump to it.
For development you never bother with the flash. Just use JTAG to copy
the 64KB code into RAM and jump to it. Avoid the big delay needed to
write the flash.
I have these chips on a serial line. If the flash signature is invalid
the ARM ROM will read from serial. So for each debug cycle I use the
serial line to go straight to RAM and avoid the flash.
The ARM ROM is very useful. There is a pin on the chip that erases the
flash. Erasing the flash makes the signature invalid. Use the serial
line to load in a new version of the software and include a little
routine to write it into the SPI flash. No JTAG needed in the field.
>
>
>>
>> > > +
>> > > +proc run {file} {
>> > > + puts "loading $file into location 0x00400000 and executing..."
>> > > + soft_reset_halt
>> > > + load_image $file 0x00400000
>> > > + reg pc 0x00400000
>> > > + resume
>> > > +}
>> >
>> > That's specific to your work environment; don't include it
>> > in a file that's intended to be general purpose.
>>
>> It's a handy procedure for anyone using the mc13224v to run an
>> images. Is there anyway to include it or something like it?
>
> Well, "handy" doesn't seem sufficient to require everyone using this
> chip to have that.
>
> This is however also sufficiently obvious (though I'd just "halt")
> that most OpenOCD users should be able to whip that up easily.
>
>
>> Are you worried about "run" interfering with some other name or do you
>> not like that it always goes to 0x00400000?
>
> Those are both issues. But more to the point, not everyone using
> OpenOCD will need or want that ... and anyone who does need it
> can easily craft their own.
>
> That's more or less just a variant of a script already included in
> the User's Guide: section 5.5 "Project-Specific Utilities", the
> very first script. (You could "resume 0x00400000" and that would
> be just a bit more concise.)
>
> - Dave
>
> _______________________________________________
> Openocd-development mailing list
> [email protected]
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
--
Jon Smirl
[email protected]
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
