Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 123 — Parallax Forums

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

1120121123125126160

Comments

  • Cluso99Cluso99 Posts: 18,066
    IIRC it's ozprop (Brian) who has the debugger for the current P2 revision.

    BTW I would rather have a P1B 3-5 years ago than a P2 next year or later.

    Even without any further tweets, a production P2 is almost unachievable for 2018 :(
  • cgraceycgracey Posts: 14,133
    Sorry, I've been up for 24 hours. Going to bed now. Hey, turn that frown upside down.
  • evanhevanh Posts: 15,126
    Ok, I'll respond to a couple of points here:
    One: It seems that no one actually wants the debug system the way it is. What Roy and JMG are really wanting is JTAG.

    Two:
    jmg wrote: »
    Yup, and any chip that targets the hard real time edge, cannot use 'printf'
    Hanging off interrupt code without any loss is no biggie, just mailbox it to the print routines. And on tiny chips using assembly, obviously not literally using "prinf()". I used a serial port puts() like assembly routine for my Prop2 testing.

    It's all just perception. Debuggers are gimmicks that people think are important.

    That said, in systems where the documentation sucks and licensing makes it impossible to acquire all the right info, then sure, JTAG queries can help speed up reverse engineering (Illegal under DMCA of course) ... Happily not of any benefit on the Prop.
  • cgracey wrote: »
    Neat ideas, Potatohead. I wish there were some ways to graphically convey what the mnemonics do. Assembly Language represents a complicated set of concepts which don't easily lend themselves to simple graphical representations.

    That is worth some thought. They don't. Trouble is context. Moving or setting bits mean very different things, depending on what they represent.


  • Can we drop the "debuggers are good/bad" part of the discussion, please? It's clear that a debugging capability will be in P2. If you don't want to use it, that's perfectly fine. If you do want to use it, that's fine too. There is no "one right way."
  • cgraceycgracey Posts: 14,133
    edited 2018-03-10 16:58
    Brian, Peter, have either of you tried out that file yet?
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    If a BRK sits at a location that is getting skipped, it doesn't execute, but gets skipped, as expected. Same with the address-match breakpoint.
    Cool, the earlier wording had me unsure what was happening...

    cgracey wrote: »
    I got rid of the dedicated BRK ($00000001) and renamed SETBRK to BRK. This way, when BRK is used outside of the debug ISR (in user code) it can generate a breakpoint AND pass an 8-bit value to the debug ISR (BRK #/D, D[7:0] is passed). This should allow for some flexibility in how debugging can be implemented.
    Nice. That allows compact implementation of things like emulation of Break-after-count, where the debug stub quickly returns, stealing the least time.

    cgracey wrote: »
    I am thinking that having a background debugger that can always be put to work without any special setup or consideration is going to be quite nice.
    It will be more than nice, it will be important to the success of P2 family.
    Debug over RESET could be important on smaller members, on 100 pins, most designs can tolerate a 'dedicated pin'.
    cgracey wrote: »
    I wish I could get REP(eat) more debug-friendly. I'll look into, but it will be a bear to change.
    If it is easy, sure, but REP is not going to be widely used, and there can be 'almost as fast' version that are debugable.

    C users are already quite used to 'almost as fast' debug, as the C-optimizers are usually turned OFF for debug, in order to have Source lines match code generated.
    ASM users are not so tolerant.
  • jmgjmg Posts: 15,140
    evanh wrote: »
    It's all just perception. Debuggers are gimmicks that people think are important.
    Nice point, it is very true that "people think are important", and those are your customers.
    You can ignore that, or you can provide the customer what they think is important.
    Simple commercial choice. Which would you make, if you wanted to sell more silicon ?

  • cgracey wrote: »
    Brian, Peter, have either of you tried out that file yet?
    Not yet, it was too late last night and now too early Sunday morning. I will try it out today though.

  • jmgjmg Posts: 15,140
    For a simple litmus test of the current state of the play around debuggers, let's see what other chip vendors consider important.

    A decade ago, debug connection alone was common, now a minimum is debug and UART COM connection, as sometimes run-time reporting is useful too...


    Take a look at
    http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega4809_Xplained_Pro_Schematics.pdf

    This is a moderate cost eval board, that includes a HS-USB host MCU, and that manages
    * Debug link, (1 wire) to support Break/Step/Pgm - this is the backbone of development
    * COM port for serial link, printf / logging / reporting use
    * i2c
    * SPI
    * GPIO

    That's a lot of useful connectivity for students and developers.

    or, a little bit simpler
    http://www.nuvoton.com/resource-files/UM_NuTiny-SDK-N79E715_EN_Rev2.01.pdf
    https://www.digikey.com/products/en/development-boards-kits-programmers/evaluation-boards-embedded-mcu-dsp/786?k=EFM8UB3

    These both have
    * Debug Link
    * COM port
  • cgraceycgracey Posts: 14,133
    cgracey wrote: »
    Brian, Peter, have either of you tried out that file yet?
    Not yet, it was too late last night and now too early Sunday morning. I will try it out today though.

    No rush, Peter. Whenever you get to it will be fine. I'm hoping I made the file correctly. I haven't done it in a while.
  • evanhevanh Posts: 15,126
    jmg wrote: »
    You can ignore that, or you can provide the customer what they think is important.
    Simple commercial choice. Which would you make, if you wanted to sell more silicon ?
    I see, this isn't really about debugging at all now is it. We went all over the IDE wish-list thing years ago. You wanted many millions spent on some humongous flashy IDE back then too.

    I'll settle for a working Prop2, thank you very much.
  • Well, this is basically done. Didn't seem all that big in the scheme of things. So now it's on work toward of working prop 2. With the bonus of providing pretty damn good debug for the people who need it. Or who want it.
  • I wrote that last comment with Google Voice sorry for the typos.
  • cgraceycgracey Posts: 14,133
    edited 2018-03-10 22:34
    No problem. I think we have this in good order now.

    Anxious to hear how it fares with Brian and Peter. I hope the "documentation" I provided makes sense.
  • jmgjmg Posts: 15,140
    evanh wrote: »
    jmg wrote: »
    You can ignore that, or you can provide the customer what they think is important.
    Simple commercial choice. Which would you make, if you wanted to sell more silicon ?
    I see, this isn't really about debugging at all now is it. We went all over the IDE wish-list thing years ago. You wanted many millions spent on some humongous flashy IDE back then too.

    I'll settle for a working Prop2, thank you very much.

    Thanks for the giggle, nowhere does my post mention IDE, nor millions... *rofl*

  • jmgjmg Posts: 15,140
    potatohead wrote: »
    Well, this is basically done. Didn't seem all that big in the scheme of things. So now it's on work toward of working prop 2. With the bonus of providing pretty damn good debug for the people who need it. Or who want it.

    Yup, all sounds good to me :)

  • Chip
    V32 flashed Ok in BeMicro-A9 board.
    Running tests now.....
  • cgraceycgracey Posts: 14,133
    ozpropdev wrote: »
    Chip
    V32 flashed Ok in BeMicro-A9 board.
    Running tests now.....

    Super! Does it all make sense?

    Ask any questions here and I will answer.
  • Cluso99Cluso99 Posts: 18,066
    FWIW I am not against debuggers. What i see is another simple tweek that ends up taking days/weeks/more. Real silicon is still a twinkle in my eye, and time to real silicon seems to endlessly increase.

    We all have that simple addition that will take just an hour or two.

    But we have no silicon. There is little testing happening any more. I know I haven't been testing much after I wasted months years ago with a debugger/monitor in LMM mode before we got hubexec. Continual changes meant that I never re-wrote it. Now I have gone back to work, I cannot seem to find the time to do any P2 testing, even if I had the motivation to do so which I am sad to say I no longer have.

  • Chip
    When a BRK #/D fires a debug interrupt and passes a 8 bit value to the debug ISR where is the value read from?
    Is it the top 8 bits of the GETINT wz variant?
    GETINT D WZ - writes {8'b0, CALL_depth_during_SKIP[3:0], INT_select[3:1][3:0], INT_state[3:1][1:0], STALLI, SKIP_mode} into D, clears Z
    
  • ozpropdev wrote: »
    Chip
    When a BRK #/D fires a debug interrupt and passes a 8 bit value to the debug ISR where is the value read from?
    Is it the top 8 bits of the GETINT wz variant?
    GETINT D WZ - writes {8'b0, CALL_depth_during_SKIP[3:0], INT_select[3:1][3:0], INT_state[3:1][1:0], STALLI, SKIP_mode} into D, clears Z
    

    Yes, according to Chip's Verilog image.
    High byte is zero when not in the debug ISR.
  • YanomaniYanomani Posts: 1,524
    edited 2018-03-11 01:12
    jmg wrote: »
    cgracey wrote: »
    I am thinking that having a background debugger that can always be put to work without any special setup or consideration is going to be quite nice.

    It will be more than nice, it will be important to the success of P2 family.
    Debug over RESET could be important on smaller members, on 100 pins, most designs can tolerate a 'dedicated pin'.

    If I'm understanding it right, in case of the 100-pin package, are you suggesting that some specific I/O pin, amongst the 64 available ones (P[0:63]), would be elected to have the capacity to be enabled as the conveyor of an externally generated BRK request?

    And, in cases of lower pin-count packages, RESn would be the means for the BRK signal to feed the pin-sharing discriminator (No Action-RESn-EXTBRKn).

    If this is the case, then +1.

    It would also be great, a kind of historical homagge, if we could use something like a dual-logic-level adapted signal, kind of a composite video sync, down from 1.8V to GND as being the logic level to trigger RESn.
    And when external BRK is enabled, if we could superimpose something like a full 3.3 V luminance signal excursion, to be internally discriminated as being EXTBRK trigger.
    Sure, its nature would be a lot more analog than digital, but anyway, it woud be neat.



  • A debugger being shown, in context, for low level programming. In this case, it's a 68K, on a SEGA Megadrive (Genesis in the US).

    For most of us, easy to follow. For most of us, just seeing the assembly program, it's easy to follow, requiring only domain knowledge of the Megadrive for context.

    A P2 is similar in concept. It's got lots of toys built in. People are not going to understand these, without some context, documentation, sample programs.

    I don't use debuggers much, but Roy is correct. I also don't work on huge programs. Huge, low level programs definitely benefit from these kinds of tools. In fact, the reverse engineering community has been working hard on visualization means and methods to make understanding these things, at the basic, low level understandable to more people more easily.

    Here's an example of that:

    (actually, I have to find it, stand by)
  • jmgjmg Posts: 15,140
    Yanomani wrote: »
    If I'm understanding it right, in case of the 100-pin package, are you suggesting that some specific I/O pin, amongst the 64 available ones (P[0:63]), would be elected to have the capacity to be enabled as the conveyor of an externally generated BRK request?

    There are 2 ideas here ?
    An external BRK pin, (externally generated BRK request) Chip has mentioned 'in passing', but it was not clear how that was set up, or if it is in the latest Verilog.
    I'm talking mainly about the Debug link, which is the pin(s) the debug kernel chooses to use for TX.RX to the PC host.

    Because Debug kernel is downloaded, and not (currently?) in ROM, any pin is possible, but likely defaults would be the Boot TX.RX and BOOT SPI pins.
    Multiple Debug kernel designs are likely, as some will try to use Boot TX.RX for simplicity, even tho that conflicts with a separate user COM link.
    Others may decide a separate COM link should work during debug too, and select some Boot SPI pins as the debug link.

    Yanomani wrote: »
    And, in cases of lower pin-count packages, RESn would be the means for the BRK signal to feed the pin-sharing discriminator (No Action-RESn-EXTBRKn).

    If this is the case, then +1.

    It would also be great, a kind of historical homagge, if we could use something like a dual-logic-level adapted signal, kind of a composite video sync, down from 1.8V to GND as being the logic level to trigger RESn.
    And when external BRK is enabled, if we could superimpose something like a full 3.3 V luminance signal excursion, to be internally discriminated as being EXTBRK trigger.
    Sure, its nature would be a lot more analog than digital, but anyway, it woud be neat.

    Small MCUs use RESn as the debug pathway, so as to give users free access to the valuable IO pins.
    Just how the Debug channel uses RESn varies somewhat by IC vendor & model, but usually they avoid trinary logic (to keep hardware simpler).
    SiLabs uses a custom format, that dictates a local Debug-server-MCU, but the newest Atmel debug looks to have been carefully designed to allow UARTs to be used.
    They use a BREAK and SYNC char for Autobaud, rather similar to a fast LIN bus, with timeouts to give wide-low -> HWRST.

    It's pretty much the standard to have some MCU as the USB-DEBUG bridge on the offered Eval Modules.

    That decision is still open on P2-SDK, some choices could be
    * Use another P2 - Physically large, but this demos well, and certainly can manage high link speeds.
    USB in SW is working in P2, but I've not seen bandwidth specs on that ? Can it do high MBaud links ?

    * Use a single or dual UART.(SiLabs/FTDI/EXAR) - a Standard block, and dual allows COM for user, and separate Debug Link.

    * Use a USB MCU, such as EFM8UB3 or similar. That needs code to run in the EFM8, but could manage DBG/UART/SPI/i2c links

  • Can't we just make an external BRK when needed?
  • Chip
    Debug is working nicely!
    Still playing with it all and so far everything is working as expected.
    :)



  • Maybe an alias is needed for code clarity.
    Instead of GETINIT #/D to generate an async break we could simply use BREAK #/D instead.
  • jmg wrote: »

    Small MCUs use RESn as the debug pathway, so as to give users free access to the valuable IO pins.
    Just how the Debug channel uses RESn varies somewhat by IC vendor & model, but usually they avoid trinary logic (to keep hardware simpler).
    SiLabs uses a custom format, that dictates a local Debug-server-MCU, but the newest Atmel debug looks to have been carefully designed to allow UARTs to be used.
    They use a BREAK and SYNC char for Autobaud, rather similar to a fast LIN bus, with timeouts to give wide-low -> HWRST.

    It's pretty much the standard to have some MCU as the USB-DEBUG bridge on the offered Eval Modules.

    That decision is still open on P2-SDK, some choices could be
    * Use another P2 - Physically large, but this demos well, and certainly can manage high link speeds.
    USB in SW is working in P2, but I've not seen bandwidth specs on that ? Can it do high MBaud links ?

    * Use a single or dual UART.(SiLabs/FTDI/EXAR) - a Standard block, and dual allows COM for user, and separate Debug Link.

    * Use a USB MCU, such as EFM8UB3 or similar. That needs code to run in the EFM8, but could manage DBG/UART/SPI/i2c links

    My mind has been piling years (and dust) faster than I ever thought it was (could also be a sophism, followed by some brain shortage)!

    A serial debug link, sure it's some nifty solution!
    Even using plain vanilla 9600bps, 1 start + 8 data + 1 stop, a 20-bit long break will hold the link at space for < 2.09 mS.
    Thus, anything greater than, says 3.13 mS (30-bit times), could be interpreted as a valid RESn pulse.
    Droping a 5% tolerance into de pudding will not worsen those figures, so even the internal reference-clock could be used.

    Simply genius!

Sign In or Register to comment.