Newby SAM7 USB Programming questions

Discussion about SAM7 Series and ARM7TDMI based products.

Moderator: nferre

nky_bri
Location: ky-nagoya
Posts: 4
Joined: Fri Jul 25, 2008 1:42 am

Newby SAM7 USB Programming questions

Fri Jul 25, 2008 1:56 am

Hello all. I apologize in advance if my question is a dumb one...

I'm new to the ARM world and would like to set myself straight on the programming options for an Olimex SAM7-256 USB board that I just purchased.

I want to experiment with this board and will be programming/reprogramming it quite often. Can I do this via USB and Atmel AT91-ISP utility without an external JTAG programmer? I know that the SAM-BA and the boot assist can be used but believe that it can only be programmed around 100 times with this method.

I've tried to find the answer to this on my own but am a bit confused :oops:

Thanks in advance for any help.
dariens_haircut
Posts: 23
Joined: Fri Jul 25, 2008 12:08 am

Re: Newby SAM7 USB Programming questions

Fri Jul 25, 2008 8:15 pm

Oddly, nobody ever seems to mention that, so kudos to you for noticing.

The 100 times thing is the number of write/erase cycles that the NVM bits (such as those for page locking) can endure. Unfortunately, reloading the SAM-BA bootloader with the TST pin locks the first page, and you have to unlock it before programming your firmware at address 0x100000.

You could, however, start loading FLASH at 0x102000 (or maybe even 0x101000), which would not overwrite the bootloader (and would not require you to unlock blocks). You would then have to use SAM-BA to start execution at that address. You, of course, would only be able to load images up to 248KB (or maybe even 252 KB) that way. See this thread for more info.

The FLASH endurance of 10000 cycles is far better than the NVM endurance of 100 cycles. This method also saves you from having to do the TST pin dance all the time.

I take it a step further, and load my test code into RAM and run it there, thus avoiding wearing the FLASH at all. Same idea. Load data after the copy of SAM-BA in RAM (my code can use that space (0x200000 - 0x202000) for data once my code is running if I don't plan to return to SAM-BA until the board is reset), and use SAM-BA to start executing at the RAM address. That works for me because I'm developing for SAM7S64, and the RAM in the SAM7X256 I'm developing on has the same amount of RAM as the former has FLASH (and, of course, similar innards). I would have just gotten a SAM7-H256 board and modified it, but Sparkfun was out of stock at the time.

Which specific Olimex board are you using? Are you going to be using USB in your firmware? I ask because there is a gotcha with this if you are and you're using some of their boards unmodified. My SAM7-H64 is one of them, and the SAM7-H256 is the same design.
nky_bri
Location: ky-nagoya
Posts: 4
Joined: Fri Jul 25, 2008 1:42 am

Thanks!

Fri Jul 25, 2008 9:16 pm

Thanks for the response!

To answer your question, yes I was planning on using the USB in my firmware. The board is the Olimex SAM7-256 Header board. I just purchased it 2 weeks ago. I'm planning to use the board as a realtime LQR controller in one of my projects as an autopilot/flight controller. I want the USB to communicate with Simulink as part of the controller feedback loop.

So what is the gotcha with using the USB in this manner?
dariens_haircut
Posts: 23
Joined: Fri Jul 25, 2008 12:08 am

Re: Thanks!

Fri Jul 25, 2008 11:26 pm

nky_bri wrote:Thanks for the response!

To answer your question, yes I was planning on using the USB in my firmware. The board is the Olimex SAM7-256 Header board. I just purchased it 2 weeks ago. I'm planning to use the board as a realtime LQR controller in one of my projects as an autopilot/flight controller. I want the USB to communicate with Simulink as part of the controller feedback loop.

So what is the gotcha with using the USB in this manner?
On that board, the USB DP pullup (R15) is directly pulled up to 3.3V. It is always pulled up and cannot be disabled. You need to add a circuit which enables the pullup only when PA16 is driven low. On my board, I built such a circuit with a PNP transistor (common-emitter arangement) and a 10K resistor (to limit base current) in adition to R15 (which I had to relocate). The SAM7 datasheet suggests a similar circuit which uses a FET instead.

Without this change, your firmware will not be able to tell the USB host that the SAM-BA device has ceased to exist (by raising PA16 for a certain minimum amount of time (usually on the order of 100-300ms) or that it should enumerate your new device (by lowering PA16). Doing so basically simulates unplugging the device and plugging it back in. PA16 is special in that SAM-BA knows about it, so it enables the pullup so that it can work.

Even if you were not using SAM-BA to jump into your code, there would still be a problem with the unmodified Olimex board. If your board resets (via the reset switch or some other source), there is no way to tell the host that it has happened, so it will get confused about the state of the USB endpoints. The result being that it is likely that USB won't work after a reset. Upon reset, all of the GPIO pins become inputs with pullups, so with the modification, the DP pullup will get disabled, thus telling the host that your device has disappeared. When the SAM-BA bootloader starts up, it will enable the pullup and enumerate afresh. If the delay between those events isn't sufficient for the host to notice the disappearance of your device, it is possible to remedy that in the RSTC (reset controller).

Or, you could just pull out the USB cable whenever you reset the board, which gets really old really fast, and causes wear on the connectors. Been there. Done that. Got sick of it and modded the board.
nky_bri
Location: ky-nagoya
Posts: 4
Joined: Fri Jul 25, 2008 1:42 am

Rev C1

Sat Jul 26, 2008 1:22 am

After looking at the schematic, checking the Olimex site and looking at my board it appears that R15 is no longer present. The Rev C1 boards (my board) have a slightly different setup http://www.olimex.com/dev/images/ARM/AT ... sch-C1.gif

There still is a pullup resistor R and 2 additional 300k resistors R10 and R11.
dariens_haircut
Posts: 23
Joined: Fri Jul 25, 2008 12:08 am

Re: Rev C1

Sat Jul 26, 2008 2:27 am

Resistor R is what I was calling R15. The situation with the DP pullup not being able to be disabled remains the same in the schematic which you cite.

I'm guessing R10 and R11 are there to keep the pins from floating when no device is plugged in. They probably don't hurt anything.

Olimex seem to have seen the error of their ways at some point, and rev E of the SAM7-P256 (the prototyping board, rather than the header board which we are discussing) now includes the sort of circuitry I'm talking about. Rev D of the SAM7-P256 contains circuitry for that, but it is wrong. In the diagram for rev E, FET1 and the associated resistors are the what I'm talking about.

I don't know whether they'll ever modify the header boards to do the right thing with the DP pullup. I suppose it could happen.
nky_bri
Location: ky-nagoya
Posts: 4
Joined: Fri Jul 25, 2008 1:42 am

Thanks again!

Sat Jul 26, 2008 6:27 pm

dariens_haircut, you have been a great help getting me started. Thanks again for your help! You are gold-mine of knowledge for the ARM :D Cheers
alstonamos
Posts: 1
Joined: Thu Apr 07, 2016 8:03 am

Re: Newby SAM7 USB Programming questions

Thu Apr 07, 2016 8:09 am

you could just pull out the USB cable whenever you reset the board, which gets really old really fast, and causes wear on the connectors. Been there. Done that. Got sick of it and modded the board.

Return to “SAM7 ARM7TDMI MCU”

Who is online

Users browsing this forum: No registered users and 1 guest