With white you get jtag without adding a jtag socket needed by black |
I intend to use Starterware by TI on a Beaglebone. I wish to know if I have to purchase the earlier version of the Beaglebone to do this. ( the white one) or would I be able to code with starterware via CCS to the BBB? thank you for all your responses. |
-- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. |
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/vzfp4r7ssUc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
For me jtag is a must if you want to gamble that serial port works and $89 is an issue For jtag then you could use black then your stuck flashing sd cards and guessing .you could start with black and if you have no debug then you have to solder socket on black. White uses fdti usb jtag no socket |
In my opinion there are several reasons to not to use BB White:- it is no longer available, so using it is not really future proof- the JTAG header is not very useful in general, except you buy one of the thousand Dollar processor probes from TI (the cheap 70$ variant is incredibly slow and sometimes influences the code in an unwanted way - like ISRs that are no longer called when running with the probe, SD card has to be removed during code upload and other ugly things more); so it does not really matter when you don't have one immediatelySo my suggestion: use BBB, add this JTAG header (it is not very complicated, TinCan Tools offers a ready-to use set for this), and write your own simulation that gives the possibility to run your code on a normal desktop PC. This way you have to use the probe only in case of troubles with hardware.
--
What you say is not accurate. The USB100V2 is less than $100 and is plenty fast enough.
The TinCan Tools just doesn’t work and there are several users on this mailing list that have tried and failed.
While the USB100V2 can be used for Linux Kernel code (Drivers, Modules, etc) development, it isn’t really Linux OS aware (CCSV4 did have this feature, but this was dropped in CCSV5). You can see Linux kernel source code, set breakpoints, view global and local variables, but you cannot switch to another kernel process or view many of the kernel data structures. Debugging Kernel Modules is almost impossible. For real Linux Kernel code development I recommend using Lauterbach which is Linux Kernel OS Aware, and takes advantage of the AM335x internal 32k trace buffer, but it is > $5,000.
On Wednesday, 18 June 2014 20:18:47 UTC+2, john3909 wrote:What you say is not accurate. The USB100V2 is less than $100 and is plenty fast enough.TI itself points to the fact that you need much patience when using USB100V2. I don't know what size your application has but with a .bin file above 100 kByte there is time to get a cup of coffee until .GEL file is executed and firmware is loaded.
Beside of that restarting the code on BBB does not work, so you reload the code quite often.The TinCan Tools just doesn’t work and there are several users on this mailing list that have tried and failed.TinCan Tools I mentioned are the header (that is required for Black) and an adapter to connect with the TI debugger - so just some passive pieces of metal that work fine for me. Don't have any experience with their debuggers.
While the USB100V2 can be used for Linux Kernel code (Drivers, Modules, etc) development, it isn’t really Linux OS aware (CCSV4 did have this feature, but this was dropped in CCSV5). You can see Linux kernel source code, set breakpoints, view global and local variables, but you cannot switch to another kernel process or view many of the kernel data structures. Debugging Kernel Modules is almost impossible. For real Linux Kernel code development I recommend using Lauterbach which is Linux Kernel OS Aware, and takes advantage of the AM335x internal 32k trace buffer, but it is > $5,000.I'm using it for bare metal programming with Starterware only, no Linux involved. There the debugger works quite poor, also with CCS6.
Fred
Date: Monday, June 23, 2014 at 2:18 AM
To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Subject: Re: [beagleboard] Starterware on BeagleboneOn Wednesday, 18 June 2014 20:18:47 UTC+2, john3909 wrote:What you say is not accurate. The USB100V2 is less than $100 and is plenty fast enough.TI itself points to the fact that you need much patience when using USB100V2. I don't know what size your application has but with a .bin file above 100 kByte there is time to get a cup of coffee until .GEL file is executed and firmware is loaded.Then you must be using a TCLK less than 10MHz. With TCLK at 10MHz, a 100kB image will download in seconds.
On 23 June 2014 18:21, John Syn <john...@gmail.com> wrote:Date: Monday, June 23, 2014 at 2:18 AM
To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Subject: Re: [beagleboard] Starterware on BeagleboneOn Wednesday, 18 June 2014 20:18:47 UTC+2, john3909 wrote:What you say is not accurate. The USB100V2 is less than $100 and is plenty fast enough.TI itself points to the fact that you need much patience when using USB100V2. I don't know what size your application has but with a .bin file above 100 kByte there is time to get a cup of coffee until .GEL file is executed and firmware is loaded.Then you must be using a TCLK less than 10MHz. With TCLK at 10MHz, a 100kB image will download in seconds.Sounds interesting...where can one change this value (in CCS6)?