Anyone compiled the code for BC100 with WinAVR?

Go To Last Post
31 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

I just got in the AVR BC 100 hardware and obviously would like to start out modifying the code that comes with it. It is for IAR but I would rather not use time to learn a new toolchain (before even proficient with WinAVR).

If someone already went through this and have some tips, please post PM or email.

Search words: BC100 ATtiny261 ATtiny461 ATtiny861
charger charging

Einar Sjaavik

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello again,

No luck on this.

I asked Atmel why the example code for the 466 is not available. Reply: "It's a bug, will hopefully be fixed in next release.". Huh!? Why not send it to me when asking then!? Probably because I did not tell him explicitly. Sometimes I wonder why some support people have no initiative.

I also asked if they tried compiling the Tiny code with the 4K restricted IAR Demo. Reply: No. They use the licensed version.

No GCC code available. But they suggest "porting the code should not be to big a problem."

I'd like to see their #define big !!!
I tried, I don't think they did. I read their reply as in: roll it up and stuff it.

Anyway, maybe I should not be so hard on it, the hardware is very nice, with different options on buck converter and lots of other choices by jumpers. So even if my app will just very remotely resemble a small part of the BC100 hardware, I save lots of time by not having to do my PCB version 0.00 before proving it will work. And if your app include ATtinyX5 or ATtinyX61 it's worth it's money and more for you too.

So I will recommend the BC100 hardware. But unless you use IAR tools, disregard the accompanying source. It's designed to sell IAR, not ATtiny. It's definitely not coded by the KISS principle.

Einar Sjaavik

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you talking about avr458.zip or avr463.zip ?

In either case it looks like fairly standard C so the majority of it should be useable with GCC. The areas that vary are going to be things like the interrupt definitions but there's been a lot of prior traffic on Freaks about porting IAR to GCC and how to handle this kind of thing.

Cliff

EDIT: Ah ha - finally found an interesting post from eivind that I thought you may find useful...

https://www.avrfreaks.net/index.p...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> It's designed to sell IAR...

That's somewhat unfair. There used to be a tight relationship between
Atmel Tronheim and IAR Sweden, for historical reasons. That kind of
relationship lead to a situation where IAR has certainly been the very
first C compiler that could generate code for the AVRs by its time, so
I guess that simply caused IAR to make a number of friends among the
Atmel Trondheim employees by this.

However, I can see a changing attitude lately among at least some people
who appear to be responsible in Atmel Trondheim lately to recognize
AVR-GCC as something that very much helps them selling AVR devices, and
thus ought to enjoy quite some semi-official support as well. Take it
as one sign of that changing attitude that they eventually hired Eric
Weddington so he can work full-time on WinAVR. Naturally, a changed
attitude alone doesn't automatically change all the appnote code that
has been written in the past...

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just received the BC100 and am in the processing of porting the IAR firmware to GCC. I'll post here when I have that port completed.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You could also send that code back to Atmel (avr at atmel.com). If you're
lucky, they might include it into some update of the appnote zip file.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yup, Jörg, that's the plan!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I finished the port to GCC last night and will work on testing the port over the next few days.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Jörg:

Yes, I'll admit I was typing that before calming down after reading a reply from support that I did not like. (And I'm at the business end of a support line myself.) To balance this out, I should mention I got a polite, nice, relevant, helpful and prompt support over phone from Trondheim a while back.

I'm glad to see GCC gaining support. I know for a fact several of my customers use it, and I must admit I was not out early to accept it myself.

I look forward to Kevin's port, and I'm sure I will learn a lot about porting from that one.

As for progress, I just left the IAR code to itself, tried to wrap my head around the datasheet, and now it's giving me output that makes sense. And as usual, the HW bit is just great.

It looks like it will be useful, bordering on plain fun!

Best Regards
(LA8BKA) Einar Sjaavik

Einar Sjaavik

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I posted my initial GCC port to http://www.avrcode.com/bc100/

The code compiles without error, but I've not yet tested it on hardware. Martin Thomas is doing a review of the code.

Anyone is welcome to download and try the code, but be warned: the firmware controls battery charging and errors in the code could lead to dangerous battery charging.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've uploaded a new version with excellent additions by Martin Thomas to http/www.avrcode.com/bc100/

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kmr wrote:

Anyone is welcome to download and try the code, but be warned: the firmware controls battery charging and errors in the code could lead to dangerous battery charging.

Thank you for the effort. I will have a look at it as soon as I can.

And yes, I think it was not a wise decision by Atmel to choose LiIon batteries as the default technology in the BC100. They can be very nasty (blow up) if not correctly charged. I would choose NiMh instead for experimenting. So monitor your charging closely and know the battery technology if you use LiIon.

It probably do not belong in this forum section, but I found that the FET/Totem pole driver does not control the power FET very well at low pulse width. Keep an eye (or scope) open on that one.

Einar Sjaavik

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> And yes, I think it was not a wise decision by Atmel to
> choose LiIon batteries as the default technology in the BC100.

Default? I haven't looked what the hex files are for, but I can
see there are two appnotes with source code, one for LiIon and one
for NiMH. So you've got the choice...

It's common for LiIon that any removable battery pack is equipped
with its own additional protection circuit anyway.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

According to the documentation LiIon is the one loaded in the kit. And that's exactly the choice I did not have because the source would not compile in GCC, neither would it in IAR. Not in demo mode anyway.

And LiIon have some builtin protection (overcurrent), but I have seen none with overcharge protection. I guess that's cheaper to put into the charger/phone/camera/whatever.

The NiMH is very hard to make go off with a boom/fizz unless very seriously abusing it. With the kind of currents delivered by this kit worst case would probably be a destroyed battery and a bad stink.

So I still second Kevin's warning.

Easter now over and done with, I'll try to compile Kevin's code changes and report back to conclude this thread.

Einar Sjaavik

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> And that's exactly the choice I did not have because the
> source would not compile in GCC, neither would it in IAR.
> Not in demo mode anyway.

Ah, I was under the impression that the hex code is part of avr463.zip, but
obviously it isn't. That seems stupid, yes.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I tried the GCC code- :cry:

It does not get past the JumperCheck()in statefunc.c.
Here's where the problem seems to lie:
------------

// If the PWM output can't be increased high enough -> check jumpers
// J400-J404, J407 and J408.
if (!PWM_IncrementDutyCycle()) {
PWM_Stop();
return(FALSE);
}
--------------
This code is inside a do..while loop.
The PWM_IncrementDutyCycle() code is executed only once and can be caught with a breakpoint on PWM_Stop(). But when this break is hit, then OCR1B=0x0D which is initialized value plus one. It should really not fail until OCR1B is 0xFF.

The return value seems to be in R24. Could it be clobbered by an ISR?

And to be sure it was not my actions, I tried with only on breakpoint, on PWM_Stop() to be sure I did not muck up some timing. Same thing.

Einar Sjaavik

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The breakpoint inside if (!PWM_Inc...) might be misleading. With optimization enabled (which is the default setting in the current AVR-Studio project-settings of the gcc-port) the generated machine-code for PWM_Stop()/return(FALSE) gets executed (a) if PWM_IncDutyCy() returns false _and_ (b) if abs(adcs_IBAT_tmp) > 100. I tried to reproduce this here and the increment of OCR1B works as expected. The breakpoint sometimes got hit if adcs_IBAT_tmp has been > 100 I expect that is the reason for the breakpoint-hit on your side too. But this did not happen everytime the function has been executed, in the next detection-cycle the loop ended because of a timeout. But I have to admit that I only tested in a "dry run" without batteries connected (bought NiCd instead of NiMH :-( ). Did you test with the firmware provided by Atmel? Which kind of battery do you have connected? Please try if the comment for the "previous" is a useful hint and changes the situation ("Charge current is too high -> check load and jumper J405 and J406.")

Martin Thomas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Martin!

Thanks for your reply. And I hear you regarding the effects of optimization. I tried to turn it off, but then it will not fit in the device.

It was also hard to inspect the variables used in the tests to see if they would fail or succeed. The compiler/optimizer feels very free to re-use registers that are not needed later in the code. I tried to volatile them to pull them out of the registers and into SRAM. Except from code speed and SRAM consumption, could this bite me in other ways?

This made me aware that the first test ADCS_rawBAT_tmp is the one that fails. Moving the jumpers 405 and 406 to 1/8 fixed that. Now it falls out at the bottom with a timeout.

I try with a NiCad. At this point in code it cannot detect the difference anyway. When to end charge is however different between the two, and a NiMh should be used to test that part.

I did not test the Atmel code, as that is for LiIon and I cannot babysit it to be sure it does not set my batteries on fire along with the house. I've seen how LiIon can react to wrong charging before. Very ugly! Overvoltage will do it, even if the charging current is almost zero.

Einar Sjaavik

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

einar wrote:

This made me aware that the first test ADCS_rawBAT_tmp is the one that fails. Moving the jumpers 405 and 406 to 1/8 fixed that. Now it falls out at the bottom with a timeout.

If you look it the tests done in JumperCheck the only condition that causes a "TRUE" return is

if (abs((signed int)(adcs_VIN_tmp - VIN_VBAT_DIFF_TYP - adcs_VBAT_tmp)) <	                     VIN_VBAT_DIFF_MAX ) {

VIN_VBAT_* are constants/defines and adcs_* are measured and scaled to mV in the ADC-ISR. There are some testpoints on the BC100 so it should be relatively easy to verify if the hardware-scaling (dividers) and the AD-conversion and software-scaling are processed correctly. Maybe it's just a hardware-configuration or supply-issue and (hopefully) not a problem with the software.

Not that important: Don't leave the BC100 powered to long if it can not init successfully. The eeprom-writes in Initialize() seems to be called every 8 seconds if state can not be changed to a "working" state (issue inherited from the original code). 100000 eeprom-writes will be done in ca. 12 days. Not dramatic at all since 12 days continuous "fail" is not very probable and a replacement ATtiny861 is inexpensive. Anyway, needless writes are avoided now in my current development-code which will be send to Kevin soon.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mjthomas wrote:
Anyway, needless writes are avoided now in my current development-code which will be send to Kevin soon.
Sounds like a great idea, Martin. I can also port than change to IAR and submit the code to Atmel for consideration in their next firmware release.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Martin, Kevin,

I played around with optimizations on your GCC port of the BC100 code. Turn on Linker Relaxation (-mrelax, or -Wl,-relax, in your linker flags). For me it reduced the code size by 1060 bytes.

Eric Weddington

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, Eric, I'll add that to the Makefile -- thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Eric, I added -Wl,-relax to the linker flags for GCC/avr458/Makefile and GCC/avr463/Makefile. However, on my system, that crashes ld.exe (using WinAVR20071221). I recall we had a thread about that a few months ago, but I don't remember what the root cause of the crash was.

I uploaded a new .zip file with those changes. Perhaps you wouldn't mind trying the makefiles on your system and see if you get a better outcome.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Kevin,

Can you, instead, try it with 20080402rc1? I recently compiled the BC100 code with that version and with linker relaxation without any problems.

Eric

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Very good, Eric. Actually, I was just in the process of getting that new version installed to test with :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Eric, I tested with WinAVR 20080402rc1 and get the same result: Vista opens a dialog box and tells me that ld.exe has stopped working and an empty .elf file is created. The EventViewer has the following log entry:

Faulting application ld.exe, version 0.0.0.0, time stamp 0x47eb0bc3, faulting module ld.exe, version 0.0.0.0, time stamp 0x47eb0bc3, exception code 0xc0000005, fault offset 0x0006cb83, process id 0x1a50, application start time 0x01c8927421e687e2.

Edit: The current .zip file (and git repository) have the exact Makefile that I used in GCC/avr463/

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's strange. Do you have a non-Vista machine to try it on? I'm running on XP.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sure, will do. BTW, I get an error similar error on Linux with avr-gcc 4.2.2 with the result.
avr-gcc: Internal error: Segmentation fault (program ld). I tried gdb to get a backtrace, but my avr-gcc is compiled without debugging symbols. I'll let you know how XP and WinAVR 20080402rc1 testing goes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Eric: same result on XP SP2 with WinAVR 20080402rc1 using the makefile http://git.b9.com/cgi-bin/gitweb...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Eric sent to me a makefile which does not crash. Testing the differences I found that ld.exe doesn't crash if -Wl,-gc-sections is added to the linker options. There is a significant size savings with those options.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

... and specifically the size savings comes from linker relaxation (-Wl,--relax) and unused function removal (compiler flags: -ffunction-sections, linker flags: -Wl,--gc-sections).