Stanley Meyer technology entering the age of the computer

[bussi04]

...
@bussi,
One question: Have you debugged the CAN128 with the Dragon from C::B ?
If you have, then you have showed the Dragon debugs the CAN128 contrary to Atmel statements.

You then also demonstrated you could read the manual, and setup the avarice program for debugging with the Dragon.
...
Eric

No, I didnīt debug from CodeBlocks and debugging from AVR Studio didnīt work (grey menu, I used AT90CAN128 and AT90CAN32)

Trying to debug from CodeBlocks I got the following return:

>>>
Building to ensure sources are up-to-date
Build succeeded
Selecting target:
Debug
Adding source dir: C:\therightpath\test1\
Adding source dir: C:\therightpath\test1\
Adding file: bin\Debug\test1.elf
Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints

Debugger name and version: GNU gdb 6.8
The program is not being run.
Debugger finished with status 0
>>>

I have set "produce debugging symbols" to "yes".
I downloaded the original libusb32 dll from SourceForgeNet, installed and now avarice (started from cmd-shell) makes contact to the Dragon ("avarice --Dragon").
AVR-CAN is all time connected to Dragon and running the RS232-test-prog in an endless loop.

How does gdb interact with the AVR-CAN? There seems to be no upload of the built program from WinAVR to AVR-CAN after build. Maybe I have to add any command (avarice?) in the post-build section in CodeBuild, but I donīt know which and what parameters. Is AVR-CAN resetted by gdb>Dragon before upload of the new build debug-executable?

actual post-build commands:
>>>
avr-objcopy -O ihex -R .eeprom -R .eesafe $(TARGET_OUTPUT_FILE) $(TARGET_OUTPUT_FILE).hex
avr-objcopy --no-change-warnings -j .eeprom --change-section-lma .eeprom=0 -O ihex $(TARGET_OUTPUT_FILE) $(TARGET_OUTPUT_FILE).eep.hex
avr-objcopy -O binary -R .eeprom -R .eesafe $(TARGET_OUTPUT_FILE) $(TARGET_OUTPUT_FILE).bin
avr-objcopy --no-change-warnings -j .eeprom --change-section-lma .eeprom=0 -O binary $(TARGET_OUTPUT_FILE) $(TARGET_OUTPUT_FILE).eep.bin
<<<


Any idea?

greetings,
bussi04

[Tecstatic]

According to the ATMEL documentation, the Dragon can fully support the AT90CAN32.

If everything else fails, it could be a solution to replace the CAN128 with a CAN32. We still have lots of space for sub-system experiments.

The alternative is approx. 600$ for a JTAGICE mkII.

But first lets see what can be done, as you should not be able to program the CAN128 according to the doc. but maybe you can not program above the first 64KByte, as CAN64 programming is supported.

Compare the attached zip file (disguised as .pdf file), and compare the C::B project file with your own with a text editor or meld diff viewer, or another diff program.

Take a backup of your own project file in case you fail to correctly copy in the relevant lines from from my project file into yours using a text editor.

I use these commands for some of the steps:

Program the processor fuses with the command:

avarice -2 -r -B 125Khz -W eehhll -j usb ( ee extended fuse byte, hh high fuse byte, ll low fuse byte )
example
$ avarice -2 -P at90can128 -r -B 125Khz -W fd39ce -j usb


Flash the AVR program made by C::B with the command, use your own program name:

$ avarice -2 -P at90can128 -e -p -f can_io.bin -v -j usb

Debug the program, first starting avarice in one terminal and avr-gdb in another, or by post commands in C::B:

$ avarice -2 -P at90can128 -B 4Mhz -j usb localhost:4242

The commands above is for the JTAGICE mkII, change the -2 option to the Dragon option (avarice --help).

Good luck.

Eric

[bussi04]

adding
>>>
avarice --erase --program --file $(TARGET_OUTPUT_FILE).bin --dragon
<<<
to the post-build section in CodeBlocks makes the upload of newly build bin-file to the AVR-CAN .

Thanks, now I take up your code .

greetings,
bussi04

[bussi04]

debugging works

Up to now debugging in XP works using 2 cmd-windows :

first window:
>>>
avarice -g -P at90can128 -B 4MHz -j usb localhost:4242
<<<

second window:
>>>
avr-gdb test1.elf
<gdb> target remote localhost:4242
remote debugging using localhost:4242
0x00000000 in __vectors <>
<gdb>
<<<

then I can send commands via gdb-line-command-interface: i.e. "continue" or "step". Whenever an avr command is executed those dragon leds are blinking indicating that there is an interaction between avr-gdb and AVR-CAN.

what I have learned up to now:
avarice is the connector-software to the dragon programmer/debugger. itīs connection address is "localhost:4242"
avr-gdb is a command line debugger. it connects to avarice as "remote localhost:4242".

all configuration parameters are set to at90can128.

now I have to get CodeBlocks make the same job in the GUI ...

greetings,
bussi04

[bussi04]

Hi tecstatic,

for the discrete components circuit I published at http://www.energeticforum.com/renewa...html#post75459 I want to add a connector to the pcb layout. trying to make the power drivers compatible to the discrete and to the uC driven solution there should be a common pin layout and connector design for the signals.

Do you have any details towards this subject?

and one more subject:
I have no idea how to test if the dragon can overcome the 32K limit. Any idea how I can test that without a large application program?

greetings,
bussi04

[Tecstatic]

Hi tecstatic,

for the discrete components circuit I published at http://www.energeticforum.com/renewa...html#post75459 I want to add a connector to the pcb layout. trying to make the power drivers compatible to the discrete and to the uC driven solution there should be a common pin layout and connector design for the signals.

Do you have any details towards this subject?

Not yet. maybe for the sake of easy change, we should just make the "connector board" on a standard raster test PCB, and do the connections from the uC main connectors to our interface connectors with wire wrap wire.

But as your side is fixed on your PCB, I think we should first do the puzzle on the uC pin usage.
I have not started doing that, but will do that soon.

and one more subject:
I have no idea how to test if the dragon can overcome the 32K limit. Any idea how I can test that without a large application program?

greetings,
bussi04

No, but you can try this ( I have not compiled it myself ):

The following is inserted in main.cpp, and it is the only file in the project.:

#include <avr/pgmspace.h>

unsigned char large_array[ 33000 ] PROGMEM =
{
   1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
   1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
.
.
   1, 2, 3, 4, 5, 6, 7, 8, 9, 20   // last line of record init
};

int
main()
{
   short sum;      // this is a single line comment

   sum = large_array[ 0 ] + large_array[ 32999 ];
   sum = sum + 1;  //  can also be written as; sum += 1;
   return 1;
}

In your program you have 3300 lines with the numbers, please use your editor in a smart way to do this

Tip: use the line counter to check for the correct number of lines to make the compiler happy with the size of your record initialization.

The sum + 1 line is just to have a line to set a breakpoint, to check the sum is 21.

If this works the we probably have 64K available.

With more copy paste (or scripting), the same can be done around the 64KByte limit.

But even if we only have 32K available for debug with the Dragon, thats still a lot of program memory.

As long as we don't put in large engine parameter maps, I think we have more than we need.

Can you debug with C::B now ?

Eric

[bussi04]

...
No, but you can try this ( I have not compiled it myself ):

The following is inserted in main.cpp, and it is the only file in the project.:

#include <avr/pgmspace.h>

unsigned char large_array[ 33000 ] PROGMEM =
{
   1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
   1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
.
.
   1, 2, 3, 4, 5, 6, 7, 8, 9, 20   // last line of record init
};

int
main()
{
   short sum;      // this is a single line comment

   sum = large_array[ 0 ] + large_array[ 32999 ];
   sum = sum + 1;  //  can also be written as; sum += 1;
   return 1;
}

In your program you have 3300 lines with the numbers, please use your editor in a smart way to do this

Tip: use the line counter to check for the correct number of lines to make the compiler happy with the size of your record initialization.

The sum + 1 line is just to have a line to set a breakpoint, to check the sum is 21.

If this works the we probably have 64K available.

With more copy paste (or scripting), the same can be done around the 64KByte limit.

But even if we only have 32K available for debug with the Dragon, thats still a lot of program memory.

As long as we don't put in large engine parameter maps, I think we have more than we need.

Can you debug with C::B now ?

Eric

The program doesnīt compile
>>>
main.c line 20 error: size of array 'large_array' is too large
<<<

I havenīt succeeded debugging using CodeBlocks. I have the problem that CodeBlocks doesnīt stop the debugger until it has contacted avarice via TCP.

Project>Properties> Projects/Target options>Additional commands>Before Connection/After Connection. I donīt know what commands I can put in and the Internet was not helpful.

At first I start avarice in a cmd-window.
As I have read I have added "load", "break main" and "continue" to "After Connection".
I start (build and) debug,
then dragon blinks, AVR-CAN gets erased, the debugger doesnīt accept commands. seems as if dragon hangs until avarice is terminated by ^C and (necissarily) avarice restarted.

If I use "break main" and "continue" the debugger doesnīt wait until avarice is started in the cmd-window.

Do you know the command syntax of "Additional Commands"?

greetings,
bussi04

[Tecstatic]

bussi,

Regarding the compile error, first double check your array is the right size, do you have 1 line too much.

If the size is correct, then arrays can not be larger than 32KBytes, try split the data lines into 2 arrays;

#include <avr/pgmspace.h>

unsigned char large_array_0[ 16500 ] PROGMEM = 
{
   1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
   1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
.
   1, 2, 3, 4, 5, 6, 7, 8, 9, 10   // last line of record init
}; 

unsigned char large_array_1[ 16500 ] PROGMEM =  
{
   1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
   1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
.
   1, 2, 3, 4, 5, 6, 7, 8, 9, 20   // last line of record init
};

int
main()
{
   short sum;      // this is a single line comment

   sum = large_array_0[ 0 ] + large_array_1[ 16499 ];
   sum = sum + 1;  //  can also be written as; sum += 1;
   return 1;
}

Regarding the debug problems, I remember I also had to fiddle with the JTAGICE.

Don't waste your time on this, let me have a look tomorrow, then I maybe remember the cause of the trouble (I solved it 2 years ago and don't remember the details right now).

Eric

[bussi04]

success!!!

I built a file with 7 allocated arrays :
>>>
unsigned char large_array_0[ 16500 ] PROGMEM= ...
unsigned char large_array_1[ 16500 ] PROGMEM= ...
unsigned char large_array_2[ 16500 ] PROGMEM= ...
unsigned char large_array_3[ 16500 ] PROGMEM= ...
unsigned char large_array_4[ 16500 ] PROGMEM= ...
unsigned char large_array_5[ 16500 ] PROGMEM= ...
unsigned char large_array_6[ 16500 ] PROGMEM= ...
>>>
It builds and uploads fine and the bin-file is 115 KB in size, the elf is 119KB in size.

Using 2 cmd-windows for avarice and gdb Iīm able to single step and list the program.

Seems it works! There is no limit for debugging AT90CAN128 by Dragon .

greetings,
bussi04

[bussi04]

step by step

one step further according to CodeBlocks (Version 8.02) debugging.
the upload works as a post build step after build.
then I start avarice-connector in a cmd-window. taskmanager shows that avarice is running twice.
then I start the debugger in CodeBlocks.
the debugger does nothing but check build-necessity of the program (doesnīt build again), starts and waits. that works now.

debugger status:
>>>
Adding file: bin\Debug\testlimit.elf
Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Connecting to remote target
Setting breakpoints
Debugger name and version: GNU gdb 6.8
Connected
In __vectors () ()
<<<

then the debugger hangs. No commands, no quit, no debugging window informations available (all menu points grey).
all time the dragon led is blinking, avr-gdb must be killed by taskmanager, then avarice terminates but dragon leds continue blinking.
error message (twice because avarice ran twice):
>>>
gdb communications failure: connection reset by peer
gdb communications failure: connection reset by peer
<<<
it helps to restart avarice, then dragon gets normal and avarice can be terminated by ^C.

greetings,
bussi04

[Tecstatic]

bussi,

I forgot this question:

"Do you know the command syntax of "Additional Commands"?"

It is ordinary commands, e.g. objcopy or avarice.

Regarding debugging, you are almost done. I works for me, read on.

If the debugger does not close the connection so avarice exits, when ending the debug session, you must kill avarice manually.

You can not have two running avarice programs sharing the same port number.

I have debugged two AVRs simultaneously with two two screens on the same PC with 2 C::B programs, each being connected to its own instance of avarice.

The two running avarice programs then of cause have their own unique port number.

-----------------

In C::B click Settings->Compiler and debugger

Click in left pane "Debugger settings"

Remove the check mark from "Auto build project to ensure up-to-date"
Click "OK"

Insert a a character in you main file and erase it again to "touch" the file, so build will start compiling.

Then in the "build log" you will probably see an error when trying to download the program. Please post if download of the program works for you.

From the command window (not in C::B) issue the command below, if it did not work inside C::B:

$ avarice -g -P at90can128 -e -p -v -f your_file_name.bin -v -j usb

That should work OK.

Then issue the command:

$ avarice -g -P at90can32 -B 4Mhz -j usb localhost:4242

So avarice listens for commands at port 4242 with device 1t90can32.

In C::B click the "Debug / continue" button.

And you should see the yellow arrow pointing at the first code line in your main program.

I tested that step, toggle breakpoint, continue and watch variable works OK.

When I continue the program stops at the breakpoint.

I will not spend more time testing. I assume this will work at least until we cross the 32K barrier.

With my JTAGICE and my JTAGICE mkII the program download works OK from within C::B.

This seems not to be the case for the Dragon, where we must program in the external command window.

So this takes two up-arrows and an enter key to do manually in the command window.
Not much of a problem if you can save approx. 240$ buying the Dragon instead of the JTAGICE mkII.

Let me hear what you find.

Eric

[bussi04]

Complete success debugging in CodeBlocks
It also worked for the large array-program!

Thanks so much for your support .
The only command I had to add to put the debugger in line was "break main" in "Additional commands".

Ready for takeoff ...

bussi04

[Tecstatic]

bussi,

Nice to hear, then you are ready to develop for the AVR uC.

However we have to do the same with wxWidgets on the PC only.

I have just started to write the driver for the LCD display.

The driver is put in a class. In C++ a class is like a struct in C, with the addition of code also.
The class has several properties we will see gradually. One property is its interface which is defined in a .h file which is included in the corresponding .cpp file, which implements the functionality of the interface.

The LCD driver class when ready, can be replaced with another class sharing the same .h interface, when the target is the PC.

Then we can simulate the LCD on the PC screen.

Adding buttons to the simulation, we can simulate the buttons on my new SUI PCB (Simple User Interface).

This way we can make the "whole" menu programming to select an application, and then adjust the parameters without running the program on the AVR. This is a development time saver.

Besides that, everyone with a PC, who follows the instructions in this thread can also do this without investing a single $, as all is free SW, no invoice

This way everyone of you readers can learn the skills to do more advanced timing for your experiments.


Bussi, in case you have some spare time, download the data sheet for the AT90CAN128 and read the port and timer sections.

http://www.atmel.com/dyn/resources/p...ts/doc7679.pdf

----

Application of ports and timers fetched from this page:
Atmel Products - Application Notes

http://www.atmel.com/dyn/resources/p...ts/doc1493.pdf
http://www.atmel.com/dyn/resources/p...ts/doc2505.pdf

---

This design note is nice for general tips when making PCB layouts:
http://www.atmel.com/dyn/resources/p...ts/doc1619.pdf


--------------------

Regarding the connectors let me suggest the following pin-out for the interface:

The VIC connector is a 10 pin header like the JTAG connector on the AVR-CAN.

Pin 1 Pulse, logic control signal for the switch transistor.
Pin 2 Sres1 The signal is clipped on the VIC PCB to reduce noise on the controller.
Pin 3 Sres2 The signal is clipped on the VIC PCB to reduce noise on the controller.
Pin 4 reserved ( NC )
Pin 5 VSAnalog, measured analog supply voltage scaled to 0..5V.
Pin 6 reserved ( NC)
Pin 7 VAnalog, Analog control value 0..5V controls the VIC supply voltage
Pin 8 SAmp, Analog value represented VIC primary current by a scaled voltage 0..5V
Pin 9 GND
Pin10 VCC, logic supply for the VIC logic and analog circuits

We have no ordinary connector for the EEC, as this will be a plastic fiber connection, when we identify a communication fiber link with suitable specs.

bussi, do you agree with the connector suggestion ?

Eric

[bussi04]

...
Regarding the connectors let me suggest the following pin-out for the interface:

The VIC connector is a 10 pin header like the JTAG connector on the AVR-CAN.

Pin 1 Pulse, logic control signal for the switch transistor.
Pin 2 Sres1 The signal is clipped on the VIC PCB to reduce noise on the controller.
Pin 3 Sres2 The signal is clipped on the VIC PCB to reduce noise on the controller.
Pin 4 reserved ( NC )
Pin 5 VSAnalog, measured analog supply voltage scaled to 0..5V.
Pin 6 reserved ( NC)
Pin 7 VAnalog, Analog control value 0..5V controls the VIC supply voltage
Pin 8 SAmp, Analog value represented VIC primary current by a scaled voltage 0..5V
Pin 9 GND
Pin10 VCC, logic supply for the VIC logic and analog circuits

We have no ordinary connector for the EEC, as this will be a plastic fiber connection, when we identify a communication fiber link with suitable specs.

bussi, do you agree with the connector suggestion ?

Eric

Yes, I agree to the connector design and the optical connection to the HV related parts.

According to wxWidgets I have understood so far that itīs a platform independent runtime (/development?) environment. Before I can install it I need more informations how to integrate in CodeBlocks. I suggest the best way to do this is wait for a piece of SUI sw from you and get those parts linked together. Do you agree?

greetings,
bussi04

[Tecstatic]

bussi,
Thank you for the feedback testing the Dragons capabilities.

Do you program the uC from within C::B or do you use the command window for programming ?

If so could you please send me the magic words to make it work.

Programming the uC from within C::B does not work for me for the Dragon, it does work for the JTAGICE.

---

You can find instructions on the net how to install wxWidget on windows to develop user applications.

You install libraries and header files.

When you get the sui.cpb C::B project file, then your installation should be ready to do wxWidgets user interface development.

Eric