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.
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.
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."
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.
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'.
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.
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 ?
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.
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.
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*
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.
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
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.
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.
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.
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
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.
Comments
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
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: 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.
That is worth some thought. They don't. Trouble is context. Moving or setting bits mean very different things, depending on what they represent.
Nice. That allows compact implementation of things like emulation of Break-after-count, where the debug stub quickly returns, stealing the least time.
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 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.
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 ?
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
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.
I'll settle for a working Prop2, thank you very much.
Anxious to hear how it fares with Brian and Peter. I hope the "documentation" I provided makes sense.
Thanks for the giggle, nowhere does my post mention IDE, nor millions... *rofl*
Yup, all sounds good to me
V32 flashed Ok in BeMicro-A9 board.
Running tests now.....
Super! Does it all make sense?
Ask any questions here and I will answer.
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.
https://forums.parallax.com/discussion/comment/1429877/#Comment_1429877
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 ZYes, according to Chip's Verilog image.
High byte is zero when not in the debug ISR.
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)
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.
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
Debug is working nicely!
Still playing with it all and so far everything is working as expected.
Instead of GETINIT #/D to generate an async break we could simply use BREAK #/D instead.
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!