What I mean "interface" is not debug adaptors, and program_mode may be
debug_mode in OpenOCD.
Vsprog support program only, so I use program_mode.
For Cortex-M3, there shoudl be JTAG and SWD debug mode, so it need JTAG and
SWD "interfaces".
And For AVR ISP, SPI "interface" support will be needed.
So this is the framework for managing all these "interfaces".
This feature is mentioned some time age in the list, although I think JTAG
and SWD is enough for OpenOCD.
But if OpenOCD is plan for "interfaces" other than JTAG and SWD,
I can provide an example how they can be managed.
2010/3/4 David Brownell <davi...@pacbell.net>
> On Tuesday 02 March 2010, simon qian wrote:
> > I think it's the time to implement this feature.
>
> Depends what you mean by $SUBJECT, or "interface".
>
> I'd tend to think "multi-transport" support would be more important
> to have than supporting multiple debug adapters a the same time.
>
>
> > For STM32 JTAG/SWD support, this feature is MUCH more difficult than the
> > change in ADIv5 code.
>
> More "pervasive", sure. On the other hand, it's a lot simpler
> at a conceptual level ...
>
>
> > I demonstrate the multi-interface framework in vsprog, which is the
> > programmer for Versaloon supporting
> > JTAG/SWD/SPI/UART/USART/IIC/PSoC_ISSP/LPC900_ICP/C8051F_C2/STM8_SWIM and
> so
> > on.
> >
> > Every interface has an ID(bit-mask):
> > // interfaces
> > #define USART (1 << 0) // UART and USART
> > #define SPI (1 << 1)
> > #define I2C (1 << 2)
> > #define GPIO (1 << 3)
> > #define CAN (1 << 4)
> > #define CLOCK (1 << 5) // clock output
> control
>
> I have no idea what most of these would be ...
>
> ... however you will notice that there is now a flag word
> called "jtag_interface.supported". I had imagined would soon
> grow at least DEBUG_CAP_SWD to indicate a dual-mode JTAG/SWD
> adapter.
>
>
>
> > #define ADC (1 << 6) // analog to digit
> > #define DAC (1 << 7) // digit to analog
> > #define POWER (1 << 8) // power output control
> > #define ISSP (1 << 16) // PSoc_ISSP
> > #define JTAG_LL (1 << 17) // similar low level
> > driver to OpenOCD JTAG drive, used in SVF Player
> > #define JTAG_HL (1 << 18) // A high level driver
> > used in MCU support
> > #define MSP430_SBW (1 << 19)
> > #define C2 (1 << 20) // C8051F_C2
> > #define MSP430_JTAG (1 << 21)
> > #define LPC_ICP (1 << 22) // LPC900_ICP
> > #define SWJ (1 << 23) // acutally it
> should
> > be SWD
> > #define SWIM (1 << 24) // STM8_SWIM
> > #define HV (1 << 25) // High Voltage
> > control, some targets including AVR/PIC need High Voltage support
> > ......
> > Disadvantage is that the number of interfaces is limitted, if using
> 64-bit
> > integer, ONLY 64 interfaces can be defined.
>
> There are 45 tcl/interface/*.cfg files today, so if you're using the
> word "interface" to mean "debug adapter" and want to assign one bit
> to each of them, I can see how that would be a problem.
>
> But we're not talking about that many transports, so far as I understand.
> And I'm fairly sure we'll also need a way to map strings to whatever kind
> of transport ID we end up using. My first thought would be to use
> pointers to some kind of per-transport struct.
>
>
> > Every target must define a interface_needed according to different
> > program_mode.
> > For AVR:
> > const struct program_mode_t avr8_program_mode[] =
>
> OK, now I'm not following much at all. Many targets won't have
> options here; e.g. they're JTAG-only.
>
> Plus by "program_mode" you suggest flash writing, not debugging ...
>
> Agreed that if we want to support, for example, various ROM codes:
>
> + Programming Stellaris chips over UART, SSI, or I2C, using their
> Boot Loader, which "is executed from the ROM when flash is
> empty and is used to download code to the flash memory of a
> device without the use of a debug interface" (or on some
> chips can be invoked by application firmware)
>
> * Programming LPC17xx chips over UART using their Boot Loader
> in ISP mode
>
> * ... and I don't doubt that there are more examples of ways
> vendors let firmware be loaded onto chips, without using any
> debug-capable link
>
> Then we'd need to add a "program mode for those targets. But not all
> targets have them -- not even all microcontrollers -- so not all would
> need to define such a thing.
>
> There is one similarity I see between talking to chips over e.g. UART
> vs JTAG or SWD ... initializing OpenOCD would be very different from
> the current "everything uses JTAG" model. But in the case of wanting
> to talk to a bootloader to program the chip ... there's more to it
> than that: we wouldn't even be able to consider using the link to
> debug, with GDB. It would be a program-only link.
>
> So this suggests two new major flavors of mode for OpenOCD. One
> would be the transport type (JTAG, SWD, UART, etc) ... another would
> be called maybe "operation" type: "debug" or "program".
>
> Previously everything has assumed "debug" via "JTAG".
>
> - Dave
>
>
> > {
> > {'i', SET_FREQUENCY, SPI | GPIO}, // ISP mode, SPI and GPIO(for
> reset
> > control) is needed
> > {'j', SET_FREQUENCY, JTAG_HL}, // JTAG mode, JTAG_HL is needed
> > {'p', "", HV | GPIO}, // High Voltage
> > Parallel Mode, HV and GPIO
> > {'s', "", HV | GPIO}, // High Voltage
> Serial
> > Mode, HV and GPIO
> > {0, NULL, 0}
> > };
> > For STM32:
> > const struct program_mode_t stm32_program_mode[] =
> > {
> > {'j', SET_FREQUENCY, JTAG_HL}, // JTAG mode, JTAG_HL
> > {'s', "", SWJ}, // SWD mode, SWJ
> > {'i', USE_COMM, 0}, // ISP mode, ComPort
> on
> > PC
> > {0, NULL, 0}
> > };
> >
> > When initializing dongle, a interface_supported should be returned to
> > indicate the supported interfaces.
> > // init programmer capabilities
> > cur_programmer->init_capability(cur_programmer);
> >
> > RESULT versaloon_init_capability(void *p)
> > {
> > struct programmer_info_t *t = (struct programmer_info_t *)p;
> >
> > t->init = versaloon_init;
> > t->fini = versaloon_fini;
> >
> > t->interfaces = (SPI | GPIO | ISSP | JTAG_LL | JTAG_HL | SWIM
> > | C2 | MSP430_JTAG | MSP430_SBW | LPC_ICP | SWJ);
> > ......
> > // SPI
> > t->spi_init = versaloon_spi_init;
> > t->spi_fini = versaloon_spi_fini;
> > t->spi_config = versaloon_spi_config;
> > t->spi_io = versaloon_spi_io;
> > ......
> > // GPIO
> > t->gpio_init = versaloon_gpio_init;
> > t->gpio_fini = versaloon_gpio_fini;
> > t->gpio_config = versaloon_gpio_config;
> > t->gpio_in = versaloon_gpio_in;
> > t->gpio_out = versaloon_gpio_out;
> > ......
> > }
> >
> > Check whether the specified mode of the target is supported.
> > // init and check programmer's ability
> > i = cur_target->program_mode[program_info.mode].interface_needed;
> > if ((cur_programmer->interfaces & i) != i)
> > {
> > LOG_ERROR(_GETTEXT("%s can not support %s in the mode defined.\n"),
> > cur_programmer->name, cur_target->name);
> > free_all_and_exit(EXIT_FAILURE);
> > }
> >
> > And then, target related code could call the specified interfaces.
> > // init
> > spi_init();
> > reset_init();
> >
> > // use avr8_isp_frequency
> > spi_conf(pi->frequency);
> >
> > // toggle reset
> > reset_clr();
> > reset_output();
> > delay_ms(1);
> > reset_input();
> > delay_ms(1);
> > reset_clr();
> > reset_output();
> > delay_ms(10);
> >
> > // enter into program mode command
> > cmd_buf[0] = 0xAC;
> > cmd_buf[1] = 0x53;
> > cmd_buf[2] = 0x00;
> > cmd_buf[3] = 0x00;
> > poll_byte = 0;
> > // ret[2] should be 0x53
> > spi_io(cmd_buf, 4, &poll_byte, 2, 1); // send out 4 bytes in
> cmd_buf,
> > receive 1 byte from the 2nd byte into poll_byte
> > if ((ERROR_OK != commit()) || (poll_byte != 0x53))
> > {
> > return ERRCODE_FAILURE_ENTER_PROG_MODE;
> > }
> >
> > --
> > Best Regards, SimonQian
> > http://www.SimonQian.com <http://www.simonqian.com/>
> >
>
>
>
--
Best Regards, SimonQian
http://www.SimonQian.com
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
