Setting fuse bits during runtime?

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

Is it possible to set fuse bits during runtime?

If not, can I connect my I/O ports with JTAG ports and make them act as a JTAG programmer and then change the fuse bits? If yes, then which?

Would self-programming like explained above be easier with JTAG or PDI?

 

My microcontroller is ATXMEGA128A1 on a readyboard and has USB communication with USARTC0 via a VLSI chip.

My idea is that all students in the classroom who have their readyboards are able to control those bits using a terminal that communicates with my Monitor Program through USB to USARTC0.

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

Foxcat385 wrote:

If not, can I connect my I/O ports with JTAG ports and make them act as a JTAG programmer and then change the fuse bits? If yes, then which?

 

If you mean on the same device, then I'm pretty sure the answer is no.

Think about it : Programming is a special mode, where the core does not run user SW because you are programming flash.

So the Flash is 'switched over' from CPU to Programmer with MUXes.

 

You could use another part to act as Pgmr, but then it's easier to just use a normal pgmr.

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

then I'm pretty sure the answer is no.

I'm more than "pretty sure" - it's a definite "no".

 

Modern AVRs can read their own fuses at runtime though.

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

If I had an ATtiny on the board, would this work?

1. XMEGA sends instruction via SPI to ATtiny to change fuses

2. ATtiny uses PDI to reset XMEGA and set its fuses

3. When ATtiny finishes its job, it restarts XMEGA

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

It is certainly possible to put a second uC on the PCB and use that uC as a PDI programmer for the Xmega.

One could use a terminal program, or a custom PC program, to control the second uC, and tell it how to set the Fuses on the Xmega.

 

I think, however, that this isn't a trivial undertaking.

There is an App Note on the PDI interface, to supplement the PDI programming info in the Xmega data sheets.

There are, however, several error in the App Note which makes it a bit more challenging.

 

Note that the Xmega CAN change which clock source it is using via its software.

 

Of all the things for a student to learn, why would having the target Xmega telling another chip how to reset its Fuses even be on the list?

Typically, the human uses a Programmer to set the Fuses how one wants them, and then leaves them alone.

 

If you elect to pursue this project, use the PDI interface, not he JTAG interface, and select something larger than a Tiny to be the controller uC, something like a M168.

 

JC

 

Last Edited: Thu. Feb 5, 2015 - 11:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Foxcat385 wrote:

If I had an ATtiny on the board, would this work?

1. XMEGA sends instruction via SPI to ATtiny to change fuses

2. ATtiny uses PDI to reset XMEGA and set its fuses

3. When ATtiny finishes its job, it restarts XMEGA

 

Sure - and as suggested above, debug the code on a larger part, then choose the smallest it fits in. (or add some other functions..?)

 

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

You've got me intrigued. Exactly which fuse do you feel a need to change at run time? It's a bit like having self-modifying PCB tracks! Surely the fuses are something you determine at the design stage then implement once in production?

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

Foxcat385 wrote:

Is it possible to set fuse bits during runtime?

If not, can I connect my I/O ports with JTAG ports and make them act as a JTAG programmer and then change the fuse bits? If yes, then which?

Would self-programming like explained above be easier with JTAG or PDI?

 

My microcontroller is ATXMEGA128A1 on a readyboard and has USB communication with USARTC0 via a VLSI chip.

My idea is that all students in the classroom who have their readyboards are able to control those bits using a terminal that communicates with my Monitor Program through USB to USARTC0.

 

I am sure that it would be quite possible to connect a separate micro to the PDI of each student's Xmega board.

It sounds like a recipe for disaster.    Your students will render everything unusable before you get through the first day.

 

In practice,   you set up the fuses as a one-off.      Then control everything else at runtime with regular application programs.

There are plenty of exercises for your students.  e.g.

1. different clocks.   32k RC, 2M RC, 32M RC, PLL,  DFLL, ... before you even think of crystals.

2. different interrupts / priorities

3. ADC, USART, SPI, DAC,  ... which are fairly similar to AVRs

4. DMA

5. Events

...

 

I would concentrate on these topics.    Only let the students use a protected bootloader.

 

By the final weeks of your course,    you will probably cover the subject of fuses and external programmer / debugger.

 

I would start with 'high level' apps.   e.g. how to read documentation and use ready-made libraries.

Get real projects working before you investigate writing low-level code.

 

Your opinions may differ.

 

David.

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

The students need to learn low level first and then high level. If someone doesn't learn how to garbage collect or deallocate memory before learning low level programming, they will be untidy programmers and it will be hard to relearn how to prevent memory leak in the future. That's why low level exists.

 

The fuse I wanted to change is the Watch Dog fuse so that I can set the uC to have the Watch Dog timer and a Watch Dog interrupt in case the student's program goes nowhere.

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

Watch Dog fuse

I suspect, if you are going to teach a uC class, that this should be a low priority on your list of things to do.

 

Who cares is a student's program runs amuck?  Clearly that is going to happen a lot!  One expects it to happen.

The fact that the program is lost somewhere is one of the student's first clues that their program has a bug.

 

If the hardware is well designed, for student use, then they can't hurt the hardware, no matter what the software is doing.

(No bus contention short circuits, etc., can hurt the hardware if it is well designed.)

 

The WatchDog would, to me, seem to be a safety feature useful for real world applications, and unnecessary for students who are learning the basics.

 

That said, at some point they should learn about the WatchDog, and how to use it.

But that should come well after they have a solid foundation on the general operation of the uC.

 

Just my 2 cents...

 

JC

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

Foxcat385 wrote:

The students need to learn low level first and then high level. If someone doesn't learn how to garbage collect or deallocate memory before learning low level programming, they will be untidy programmers and it will be hard to relearn how to prevent memory leak in the future. That's why low level exists.

 

The fuse I wanted to change is the Watch Dog fuse so that I can set the uC to have the Watch Dog timer and a Watch Dog interrupt in case the student's program goes nowhere.

 

Rubbish.    Garbage Collection would be part of a HLL.    You would want to teach them how to read the HLL documentation carefully and obey the rules when calling the HLL functions / methods or whatever.

 

Yes,   you could teach them how to write low-level memory allocation routines if the whole class is destined to write Compilers.

Somehow,   I suspect that your class is part of a general purpose engineering degree.     i.e. you want to teach them something useful.

 

Yes,   you can enable all the WatchDogs by default if you want to.   i.e. set the fuse as a one-off.

 

I would suggest that you start with conventional best practice HLL programming.     After the students have gaind experience,   as an interesting diversion,   you can illustrate where 'some' HLL features are inefficient,   and show how to do some low-level hacking (optimisation).

 

With luck,   your 'brighter' students will show you how to use the HLL in a better way.    e.g. better algorithms instead of hacking.

 

Don't be offended.   My views are often expressed and often rejected.

 

David.

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

Foxcat385 wrote:

The students need to learn low level first and then high level. If someone doesn't learn how to garbage collect or deallocate memory before learning low level programming, they will be untidy programmers and it will be hard to relearn how to prevent memory leak in the future. That's why low level exists.

 

The fuse I wanted to change is the Watch Dog fuse so that I can set the uC to have the Watch Dog timer and a Watch Dog interrupt in case the student's program goes nowhere.

 

I will go against the flow, and say I think this is a GOOD idea, done carefully (of course).

 

Better ISP give users FULL access to all fuses, so this merely duplicates that capability, ON the students board.

 

MCU students should know about fuses (see how many fuse default burnt questions appear here ), but no, they should not need to fiddle with them on a daily basis.

 

The feature the OP asked about gives a means to restore any student PCB to a totally known state, over a UART.

In a Class, I would consider ability that a good idea.

 

I also think it is a good idea to save not only Code, but also all fuse info & EE-init into a single HEX file, but that is another topic.

 

 

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

I didn't realize you were calling me a teacher. I'm not a teacher. I'm just a student who's the best in school in programming microcontrollers. My mentor wants me to make this Monitor Program that controls everything like an OS so that the next generations that go to the school subject of microcontrollers are able to debug their programs in real time.

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

Why not simply mandate that all user's programmer begin:

int main(void) {
  wdt_enable(WDTO_15MS);

(or however you compiler does it and with whatever default time out you think sensible).

 

But if you are writing a "monitor" presumably you could hide this enabling in your own code just as you pass control to the user's program and then you could wdt_disable() when it gets back to the monitor.

 

Or, thinking about it, why would you ever NOT want the watchdog on? Surely your own (monitor) code is "controlled" and you can put in WDRs where you think long delays will occur. The sensible end user would also put wdt_reset()s in their own long loops while those who don't will trigger back to the monitor which could print them a warning to say "back in the monitor because your code was stuck in a loop for longer than N ms - read about using wdt_reset() in the course notes".

 

But now I understand more of what you are trying to achieve I wonder about your other threads asking about program base addresses and putting program A at 64K and program B at 128K or whatever. I told you there that these "client" programs are therefore going to need to have a completely different scheme for interrupt handling than the usual ISR() mechanism used on AVRs. Your monitor will "own" the IVT so your client programs are going to have to hook interrupts via RAM based pointers rather than the weak/hard link mechanism that ISR() uses. So you are going to generate a band of budding young AVR engineers who think AVR interrupts are done in a completely different way to any current AVR compiler. How do you propose to "solve" this?

 

In part this is the problem about using a micro that is (a) Harvard and (b) does not have an MMU at least an MPU. It's really the wrong architecture for such a "monitor". I'm kind of surprised your "mentor" does not recognise this.

 

EDIT: actually I had an idea for the ISR thing. The user who writes "program A" at 64K will presumably have their INT0_vect at 64K+4. So the ISR handlers in the monitor at 0 can "know" that "A" is in the program in context and just blindly perform a "JMP 64K+4" when INT0 happens and so on. If it knew "B" at 128K was in context it would "JMP 128K+4" and so on.

Last Edited: Mon. Feb 9, 2015 - 10:04 AM