FlashTools 1.0 released - Hewlett Packard

This is a discussion on FlashTools 1.0 released - Hewlett Packard ; On 2 Apr, 18:33, "Claudio Lapilli" wrote: > On Apr 2, 4:28 am, "Stefano Priore" wrote: > > > Hmm, there are still some bugs to iron out in FMAN... > > Not that I know of... let's see: > ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 23 of 23

Thread: FlashTools 1.0 released

  1. Re: FlashTools 1.0 released

    On 2 Apr, 18:33, "Claudio Lapilli" wrote:
    > On Apr 2, 4:28 am, "Stefano Priore" wrote:
    >
    > > Hmm, there are still some bugs to iron out in FMAN...

    >
    > Not that I know of... let's see:
    >
    >
    >
    > > 1) CUT doesn't work correctly: it performs always a COPY

    >
    > It works correctly. Look next to the name of the original object,
    > you'll see a "D" indicating it's a deleted object when you use cut.


    Geez, I tested it on an already deleted object (just for curiosity!)
    and obviously didn't detect the behaviour you described

    > > 2) When I pack some banks the program errors out with a "EVAL: Bad
    > > Argument Value" error. It must be noticed that I run FMAN putting it
    > > on the stack and pressing EVAL. After the error FMAN is still on the
    > > stack and no memory looks corrupted.

    >
    > If you get an error is because the operation failed, most likely
    > because you don't have enough memory to do the packing, but it could
    > happen that your bank is corrupted somehow and it's giving you an
    > error.


    I suspect some form of corruption, but what do you mean with "not
    enough memory": memory in a bank, or whole memory?

    > It's an assembler program dealing with low-level stuff, so if
    > you see an error messsage it's because the condition was detected and
    > the error delibratedly generated, no data corruption should occur in
    > such case. The stack is restored to what it was when you called the
    > program, as in any error condition. So this is not a bug, it's an
    > error condition properly dealt with.


    The error management worked flawlessly, but maybe you could use a more
    descriptive error message...

    > Still, I don't know what could be wrong with that specific bank,
    > though. Try deleting all objects first, then repack.


    OK, will do!

    Ciao,

    Stefano


  2. Re: FlashTools 1.0 released

    Hi,

    On Apr 3, 4:16 am, "Stefano Priore" wrote:

    <...>
    >
    > I suspect some form of corruption, but what do you mean with "not
    > enough memory": memory in a bank, or whole memory?


    I mean main memory. The process of repacking a bank requires copying
    all non-deleted libraries in the bank to ram, then erase the flash
    memory and rewrite all your libs back. If your bank is full, you would
    need up to 128 kbytes of free ram to perform a repack.

    <...>

    >
    > The error management worked flawlessly, but maybe you could use a more
    > descriptive error message...


    Well, there are many possible causes for the error, and all I get is a
    "carry set" for all of them, so a message would probably not represent
    the real cause anyway. The message "Bad argument value" was chosen
    because the routine receives the bank number as an argument on the
    stack, and one of the most common causes are that the bank number is
    invalid (outside the normal range). Now that I added the interactive
    part, you obviously can't choose the wrong bank anymore, but the
    message remained the same. You shouldn't see the message very often
    under normal conditions, though.

    Claudio


  3. 128K/64K banks was: FlashTools 1.0 released

    "Claudio Lapilli" wrote in message
    news:1175618143.731707.221540@n76g2000hsh.googlegr oups.com...
    > Hi,
    >
    > On Apr 3, 4:16 am, "Stefano Priore" wrote:
    >
    > <...>
    >>
    >> I suspect some form of corruption, but what do you mean with "not
    >> enough memory": memory in a bank, or whole memory?

    >
    > I mean main memory. The process of repacking a bank requires copying
    > all non-deleted libraries in the bank to ram, then erase the flash
    > memory and rewrite all your libs back. If your bank is full, you would
    > need up to 128 kbytes of free ram to perform a repack.

    X
    This is why I think that OS could be made to use 64K banks
    e.g.. the same size as Flash Physical banks
    Thus RMA/ROM banks could be doubled
    and user giving a configuration choice

    1) Main RAM 256KB continuous RAM (4 banks)
    ROM 256KB divided in 4 banks 64KB

    2) Boost RAM (stealing IRAM) to 5 banks and 320KB
    while using heavy bank-switching and slower speed on
    ROM 192KB visible (3 banks only)

    3) Boost ROM to 5 banks=320KB,
    causing less bank-switching thus speed is increased
    but RAM is down to 192KB

    4) Maximum Boost ROM 6 banks=384KB
    with "only" (remember 48GX) 128KB main RAM
    but almost no bank-switching due to
    LRU ROM bank witching algorithm

    All of this will never happen
    because of the resources of HP calc special task force
    (used to be a "division")
    that's why I suggest rather
    the PDA/Linux Xcas/Giac RPL/2 approach



+ Reply to Thread
Page 2 of 2 FirstFirst 1 2