Jump to content
43oh

uberscientist

Members
  • Content Count

    11
  • Joined

  • Last visited

Posts posted by uberscientist

  1. You might need to add the -Wall flag to your linker, in my gcc-elf it throws a warning when you are using an undefined ISR vector.

    It works now, Rick pointed out my silly mistake, I had got a new chip and didn't know TI had changed the VECTOR names in the header file >.<;

     

    I tried to edit the title of the OP with [solved] like the Arch forums, but I couldn't :(

     

    Thanks though greeeg :)

  2. @pabigot:

    Here's a gist of the makefile I'm using: https://gist.github.com/uberscientist/faba7f2050bf94d8176c

     

    I'm using an MSP430G2755.  I've also tried both ways of spelling the interrupt constant, I wasn't sure which was better.

    $ msp430-elf-gcc --version
    msp430-elf-gcc (GCC) 4.8.0 20130315 (release (msp430-130423-272)) (Red Hat/devo) [trunk revision 196673]
    

    I should check if there's a newer version... I haven't  :unsure: .

     

    So it looks like you're getting the same error for most of the MCUs?

     

    I just pushed my project as it stands (it's terribly messy, sorry) https://bitbucket.org/naked/msp-datalogger/src/b834e8e463d4af6470515bd298010fa6542ad24a/?at=fatfs

     

    Thank you very much for looking into this with me  :smile:

  3. Just for grins, try specifying a void return type on your function definition, and play around with the order of the return type and attribute declaration and the function declaration. It may be that the attribute is being associated with the implicit int return type, not with the function itself.

    Tried a bunch of different ways, even searched github for "__attribute__((interrupt" to see how others were doing it to no avail.

     

    I replied in your e2e thread, try taking off the double underscores flanking the "interrupt" keyword (but keep them around "attribute").

     

    edit: nevermind, just saw your e2e reply, it didn't work... I am not sure why, that is odd though. I may experiment with this later if I find time.

     

    Sent from my Galaxy Note II with Tapatalk 4

    Thanks for your replies! Yeah, it didn't work, but I've left the underscores off for further tests though, I just copy-pasted this from that old post.

  4. I'm getting this error:

    main.c: In function 'Timer_A':
    main.c:150:28: error: MSP430 builtin functions only work inside interrupt handlers
       __bic_SR_register_on_exit(CPUOFF);      // Clear CPUOFF bit from 0(SR)
                                ^
    makefile:23: recipe for target 'main.o' failed
    

    With this code:

    // TimerA interrupt
    __attribute__((__interrupt__(TIMERA0_VECTOR)))
    Timer_A (void)
    {
      iflag |= BIT0; // Set BIT0 flag
      __bic_SR_register_on_exit(CPUOFF);      // Clear CPUOFF bit from 0(SR)
    }
    

    For some reason msp430-elf-gcc thinks my ISR isn't an ISR :(

     

    Any ideas? I emailed one of the red hat guys who submitted the GCC patch with the function that checks whether a function is an interrupt handler or not.

  5. I finally got a MSP430G2755 -- and it worked!  I guess 1KB RAM is just not enough for the full FatFS, PetitFS seemed to work fine fwiw.

     

    I had to remove the 

    -Wl,--gc-sections

    line from the linker options, but after that it worked.

  6. Thanks for the links and words, I'll just give a progress update...

     

    I've been able to mount the FAT32 SD card, but as soon as I try to use the f_open(...) function I get that buggy behaviour I was talking about in my original post:

     

    Dim LED if I turn the GPIO pin high before calling f_open, or the LED doesn't even turn on if I place it after f_open.  It is flickering on/off very quickly so I figure the MSP430 is cycling on/off very rapidly due to the compiler creating an .elf file that is doing something screwy.

     

    Oh well, I might just ditch the FatFS idea and just use the SD card as raw flash memory like I was doing before all these shenanigans.

  7. I was looking to interface FatFS to the MSP430G2744:

     

    It has 1KB of ram (may be enough?  If not I might look into using the MSP430G2755 with 4KB of ram)

     

    I've been hacking away at getting it interfaced after doing Petit FatFS and realizing I needed to have resizable files and file creation (oops).... and that Petit has already been ported (double oops).

     

    I've been able to get it to compile with GCC, here's the FatFS branch of the project.

     

    But things are not running smoothly anymore, after I upload the code the LEDs are dim and it doesn't seem to execute past my little serial logging solution (in com.c)

     

    I've taken a break for about a week and just started looking back into this, I'm feeling sort of lost at the moment, I'm not very good at low level debugging with the open source tools.

     

    Thanks for any ideas,

    Chris

  8. Hi :)

     

    I joined today because I felt like I should since I've been using the MSP430 for a few months now.

     

    This is the project blog using an MSP430G2744 in a datalogging application.  It's a new value line chip that is very similar to the MSP430F2274 it's just lacking the opamp peripheral as far as I can see and is about $3 cheaper at qty. 1.

     

    ANYWAY, just posting because I saw I could participate in the raffle for the electronic paper.  I've had some ideas for e-paper :)

×
×
  • Create New...