MMC SD Interfacing odd error

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

Hey guys, I got my hands on a 1Gb sandisk for 10 bucks, I had no need for it, but I couldn't turn it down.. right when I got home that day I started to interface with it...

the card seems to work perfect, I can read and write all 1983999 sections of 512Kb (alot of lovely space)

but I am getting a very strange error when ever I try to add new functions, it goes like this:

with the source un-modded from where it is now, everything works I can go threw sections, read, write, and all that.

but when I tried to add a get CID function all the commands that worked before just reset or froze the whole application... after some testing I learned that it doesn't even matter what the function, if I just add:

void func(void)
{
printf("hi");
}

it stops working, very odd right?

I collected all the .lst and .c files from both a working version and a version were I only added 1 function to the main.c and it stopped working:

http://www.ph0rkeh.com/temp/debug/ <-- contains working on non-working versions...

The ONLY change between those 2 folders is I added a function (new_function) with a printf command in it, and added it to the usart menu, thats it... and it no longer works

I would really appreciate some help on this one.

edit: more details on the errors

when I scroll sections (+ - * /) seems to work ok

when I try to read (r) the freezes no response at all, I have to reset to start it back up.

when I write or clear (w c) it resets and starts at top of main again.

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

Would be helpful if you zip the files and post a download link here. Or in the least, zip them and put them in the directory. It's a pain to have to download each file by hand.

Clancy _________________ Step 1: RTFM Step 2: RTFF (Forums) Step 3: RTFG (Google) Step 4: Post

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

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

Hehe, yeah, just noticed that after I posted. Clearly I'm at least partially blind. Sorry =)

Clancy _________________ Step 1: RTFM Step 2: RTFF (Forums) Step 3: RTFG (Google) Step 4: Post

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

Does it make a difference if you clean and recompile the entire project when you add the new function?

*EDIT* Nevermind, by the looks of it, you do, as the temp file names change.

Clancy _________________ Step 1: RTFM Step 2: RTFF (Forums) Step 3: RTFG (Google) Step 4: Post

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

I don't know what AVR you are using or what compiler, but I bet your strings you are writing out with printf use all your sram memory, and mess up the stack or something.

You definitely don't want to use strings that way you are doing now.

If that is WinAVR (avr-gcc), change every printf to printf_P like this : printf_P(PSTR("blahblah %d\n"),variable);

Keywords: progmem

- Jani

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

Ah! you were right, moved all the strings and it seems to work fine now, thanks alot..

I normally do use printf_P, guess I shouldn't have gotten lazy!

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

Great! By the way, what AVR are you using? Just thinking about how much flash and sram it has.. and 20 MHz clock?

I'd also like to get my hands on some 1G SD cards at $10, but here they are up to 15 euros or something. And mailing costs would be more than the card..

- Jani

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

I was using a atmega168at 3.6864Mhz

yeah for 10 bucks its a steal, the cheapest I saw the same card for was 20 bucks, still not bad, but 50% off cant say no!

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

A couple of questions.
Were does the print statements show?
and
How do you connect the hardware?

Cheers Avi

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

Print statements go over uart and he's connected the SD card to the SPI bus, pretty much how almost everyone connects it to AVR. Correct me if I'm wrong, ph0rkeh.

*EDIT* I assume those were for your own curiosity, unless you missed that the problem's been solved already.

Clancy _________________ Step 1: RTFM Step 2: RTFF (Forums) Step 3: RTFG (Google) Step 4: Post

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

I understand that the print command is transfered to the UART but what is connected to the UART, and how is it connected, in order to show the print data?

Yes it is for my own curiosity, I'm trying to understand how it all goes together for my own adaptations.

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

Again, I'm not ph0rkeh, but it's a safe bet that the uart TX pin is connected from the AVR to the TTL input of a MAX232 (or equivalent RS-232 level shifter) and the corresponding RS-232 output of the MAX232 is connected to the RX line on the PC through whatever serial cable you care to use. Ditto for the uart RX, from PC TX through the opposite channel on the MAX232.

Then just run whatever terminal program you choose, making sure that the crystal on the AVR is acceptable to give <2% error on the baud rate you choose, and that the baud rate is the same on AVR and PC. Hyperterminal that's included with windows will work, but it's about the low-end of features.

Is that the info you were looking for?

Clancy _________________ Step 1: RTFM Step 2: RTFF (Forums) Step 3: RTFG (Google) Step 4: Post

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

correct all the way clpalmer, its just connected to a max232 to rs232 so I can play with my SD card threw br@ys terminal.

to avidb if you want the full source including the uart files I can send, the uart will work with any avr and any clock speed, it automatically gets baud for you, and the source itself should* work with any avr as well with spi.

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

Yes ph0rkeh could you please send the pertenant files to the following address rrk35@saclink.csus.edu
Also any hardware connectivity.

Im trying to interface a USB/MMC to an Atmega32 via a FTDI245 but am having a little trouble and this would be a great help.

Cheers

Cheers

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

avidb,

(sorry to hijack Brent's thread but his problem is solved anyway!)

Can you post a block diagram of what it is you are trying to achieve. If, as I suspect you were hoping to be able to plug USB memory sticks into a device built around the Mega32 then this is not going to work. The FTDI chips are to make USB slave devices and what you are talking about (if I understand your requirement) is to implement USB Host on the AVR - even if the hardware supported it I don't think you'll be able to fit an OHCI software stack into a Mega32!

Cliff

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

Not exactly Cliff.

What I would like to do is be able to plug my device (which has a MMC/SD card and USB connect) and be able to move data to the MMC/SD via USB. Also I want to be able to program the Atmega32 via USB.

If I didnt mention already Im using a FTDI245BM and Atmega32

Any suggestions?

I'll have a diagram up soon.

Cheers Avi

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

Depending on how you want to be able to "move the data" this could be difficult or easy. If you want the drive to appear to windows as a USB mass storage device, you've got a lot of work on your hands. You'll have to implement the USB protocol, device identification stuff to make windows happy, the mass storage protocol, the SCSI transfer protocol, whatever else is involved, etc, and then that's only if the 245BM has some drivers for windows that allow you to do what you want (ie. don't make the chip just appear like a parallel/serial port or something).

If you just want to have some way to throw data on and off the device, you can probably get it done a bit easier if you write your own PC SW to do it with. If you don't need the speed, you're even easier to go with something like FTDI232RL where there's no external components and you can interface directly with the uC's UART. Then you can write PC SW that opens the COM port and transfers data however you like. If you really need the speed, you'll benefit from the parallel interface on the 245BM, but you'll have to write your own "drivers" for it on the AVR.

Clancy _________________ Step 1: RTFM Step 2: RTFF (Forums) Step 3: RTFG (Google) Step 4: Post

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

Block diagram of what Im trying to do. Looks simple, but thats it.

I only need to put data on the MMC while in the device via USB. MMC is not saving data from the device.

The FTDI does come with usb drives but I havent been able to get them recognized. I have another post waiting for some info on the USB end.
titled: USB uding FTDI245BM (sorry about the spelling)

Ideas welcome and sorry about the post hijack!

Cheers Avi

Attachment(s): 

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

hey my problem is over, this thread belongs to the community now :P

ps avidb sorry im late on sending the file I was away for a couple of days, I sent the file to your email though.