SDCARD temp data logger on stellaris launchpad

Hi Hitesh,

There is an example application for USB MSC (Mass Storage Class) device for the EK-LM4F232 board.  You would need to modify it to run on the Stellaris Launchpad.  Both boards use MCUs from the same family so changes will be minor, and mostly related to the absence of the OLED display.

Here's the description from the documentation: This example application turns the evaluation board into a USB mass storage class device.  The application will use the microSD card for the storage media for the mass storage device.  The screen will display the current action occurring on the device ranging from disconnected, no media, reading, writing and idle.

You'll find the source for this in the \boards\ek-lm4f232\usb-dev-msc\ folder in both StellarisWare and the new TivaWare C series package.

@Jonathan,

Thanks this - helpful & appreciated.

IIRC - in the past there existed restrictions on both size/type of microSD cards.  Newer, higher capacity such cards often failed to properly function when married to Stellaris/other MCUs.

Would you be so good as to comment upon any such microSD card restrictions for use w/LX4F & progeny - today?  Thank you...

Right cb1, size limits apply .  The example uses FatFs though in the end, most of the limits are simply limits of FAT32.  The FatFs authors have this helpful app note.

Jonathan Guy said:

There is an example application for USB MSC (Mass Storage Class) device for the EK-LM4F232 board.  You would need to modify it to run on the Stellaris Launchpad.  Both boards use MCUs from the same family so changes will be minor, and mostly related to the absence of the OLED display.

 Hi Jonathan, this is where I started my porting to do some test on LM4S, first I removed OLED part, I cannot access subdir on SD due to program crash also on LS when a dir is in....

 Then I connected an SD2119 TFT LCD as 8 bit parallel similar to kitrinix, display turn on, it work but when I try access SD card both Usart and SPI stop working...

  I need some hint of what to check, stack appear as good, can be calling function by pointer has interaction wit some hardware peripheral?

Roberto Romano said:

can be calling function by pointer has interaction wit some hardware peripheral?

No.  The peripheral will not be affected unless code specifically writes peripheral registers.

Your best bet is to spend some time with source level debugging to figure out what code is causing the crash. 

Jonathan Guy said:

Your best bet is to spend some time with source level debugging to figure out what code is causing the crash. 

 Hi Jonathan, code is not crashing, when code exit from SDCard LS call all is working but not SPI nor uart too.

 Before to dig over, ( I am not so familiar to ARM and all was done and working on LM3S9xx)  I update CCS to latest version and library to TIVA not Stellaris, future software has to deal with this if pass all code test.

 File system access is still at version 0.04, a long time ago version from 2007, not to reinvent the well is planned to port library to latest version? Last version support multiple filesystem, long filenames and address some problem I experienced, (DIR crash is a known issue).

Here where I patched code and result from execution

int
Cmd_ls(int argc, char *argv[])
{
    unsigned long ulTotalSize;
    unsigned long ulFileCount;
    unsigned long ulDirCount;
    FRESULT fresult;
    FATFS *pFatFs;
    UARTprintf("LS Before fresult \n");
    //
    // Open the current directory for access.
    //
    fresult = f_opendir(&g_sDirObject, g_cCwdBuf);

 ********************** from here no more SPI nor UART  ******************

    UARTprintf("LS After fresult \n");
    //
    // Check for error and return if there is a problem.
    //

 Then at end of main loop:

        //
        // Otherwise the command was executed.  Print the error code if one was
        // returned.
        //
        else if(nStatus != 0)
        {
            UARTprintf("Command returned error code %s\n",
                        StringFromFresult((FRESULT)nStatus));
            GrStringDrawCentered(&g_sContext, "Command returned error code:", -1,
                                 GrContextDpyWidthGet(&g_sContext) / 2, 100, false);
            GrStringDrawCentered(&g_sContext, StringFromFresult((FRESULT)nStatus), -1,
                                 GrContextDpyWidthGet(&g_sContext) / 2, 120, false);
        }

LCD picture show sdcard access return not ready, terminal stop after first call and never work.

 Any idea what can be blocking uart and SSI?

Suspect that you have either a port/peripheral conflict or perhaps cabling issue - to suffer your plight.

More detail required - you say that you, "Cannot access SD subdir due to program crash" - but the remainder of that sentence is unclear.  (at least - to me)  Please describe in greater detail.

Issues continue: appears that you can transact w/TFT, USART & SPI.  At least individually - is this correct?  Do all three (TFT, USART, SPI) work when all 3 are connected and SW transacts with each?

Further - an SD card access, "Stops the functioning of USART & SPI."  Kindly better define, "Stops the functioning."  Assume you transact w/USART - then attempt SD card access - can you never again transact w/that USART?  (seems unlikely)  Same line of questions re: SPI.  You must better detail.

Normally/customarily rushed users will improperly "overlap" pin functions when employing multiple peripherals.  Our group for years has used multiple peripherals - and by carefully color-coding (mapping) all of the pins - such conflicts are avoided.  But to cause a working peripheral to halt - strictly upon an SD card access - makes sense only if such access has caused an over-current/voltage-drop - which may cause an incomplete MCU (or peripheral) Reset - or if such SD access has someway/somehow impacted the correct set-up/config of the "lost" USART & SPI peripherals.

Review (orderly presentation) of the perinent set-up/config code blocks (not everything) especially those involving the dreaded SD card seems a worthwhile approach...  You should list any/all pins devoted to USART, SPI and SD card - and your code which attempts config/set-up...

Final point - you removed the OLED - certain OLEDs require out-board voltage boost circuit - if that remains - and you "made contact" w/any of the peripherals mentioned - that would likely be harmful.  But for all issues to "spring" from simple SD card transaction - that would be a "first."  (and we ain't Sold...)

Jonathan Guy said:

The FatFs authors have this helpful app note.

 Hi Jonathan, link say group not found error, please can you check it?

 Hi cb1, thank for your time and sorry for incomplete details, SD and LCD are connected to a Stellaris launchpad with an LM4F120H5,

 SD card connected to pin 2,3,4,5 exactly as in LM4F232 demo board, pin 0,1 connected to UART on launchpad PCB.

 LCD pin usage:

  port B[7..0] as data port

  PD0 WR; PD1 RD; PD2 RS; CS low; (jumper removed)

  PA6 Reset;

cb1_mobile said:

Suspect that you have either a port/peripheral conflict or perhaps cabling issue - to suffer your plight.

 If I remove all call to Graph library then I can access SD card, I can cat a file, do LS but stop at end of listing, same for command CD so a trouble exist on rev 0.4  but is documented by developer and addressed on last revision.

 About conflict I removed the two 0Ohm resistor on PIN D, I can single step all code without problem, when return form SD access both SPI and USART are no more working but not the LCD driver.

 Code is from examples and nothing of my IP are on so I can post everything if it can be useful.

 Tomorrow I try again connect LA to SD and USART to see what happen on SD call...

cb1_mobile said:

Final point - you removed the OLED - certain OLEDs require out-board voltage boost circuit - if that remains - and you "made contact" w/any of the peripherals mentioned - that would likely be harmful.  But for all issues to "spring" from simple SD card transaction - that would be a "first."  (and we ain't Sold...)

 I don't own the EKLM4F232 so i got software example and I removed the driver part from software after project migration, I just connected the SD, debugged Hardware and SW, then I debugged the graphics driver of IDM-LCD35. Power supply of LCD and SD don't draw power from Launchpad regulator so no overcurrent from. Made from scratch on Launchpad no spare part are left there, just pullup to SD socket, LCD voltage regulator (with capacitor too) and wires of different colors connecting peripherals.

 Quite the same code was working on LM3S9D95 just LCD was connected with 16bit interface but this uC has too few pin to do that.

Ambitious project you have "launched" my friend - I bet we can solve this.  (at least partially - for now)

Suggest we start w/what I believe to be small/simple goal - let's get your USART to continue to work - even after your SD access.  Kindly describe how you test - and thus determine that the USART is working properly.  Beware that attachment of any MCU directly to a "real" RS232 port will likely damage the MCUs RX input.  You must impose a level translator chip or circuit to protect your MCU.  If you could transact w/Hyper Terminal or Tera Terminal - via your USART - we have a good beginning.  Can you manage this?  While this test is simple - fairly easy - my instinct screams that "fix one" will "fix ALL!" 

Once that USART connection is made and deemed reliable - attempt the shortest possible SD access.  Note then if the USART still is able to perform.  If not - seems most likely that something w/in your SD access code or HW has "disturbed" your USART set-up and/or config.  You may review all of  the key USART Registers while the USART is operational - prior to any SD access.  (best to print these - at that moment)  Then after SD access - again review those same USART Registers - are any changes visible?  If none - check then the set-up/config of each/every USART pin (must switch to GPIO view w/in your IDE) again both before and after SD access.  Again - printout always superior to "memory."  (do not ask how I know...and just where are my damn keys?)

We note that both SPI & USART emerge from your Port_A.  Thus - any incorrect or unbounded (more likely) writes to config registers of those Port_A pins will surely cause your issue.  Thus - look very, very closely at all of the SD access code - it must confine itself to PA2-PA5 exclusively - and never/ever extend into PA0/PA1.  Classically this is managed by or'ing |= or and'ing &= into the config register - never performing a "full port" write - which may inadvertently disturb an earlier (correct) setting!

Dawns just now - isn't it likely that SD access alters certain System Clocks - which would surely impact both SPI and USART?  (D'uh - now I realize this...)  If you are not spoiling set-up/config of SPI and USART port pins - via SD access - then some alteration to the clocking of both SPI and USART seems most likely.

Myself/others never liked the 2 "dead shorts" victimizing lunchpad GPIO - so that past compatibility w/vendor's likely "older, M3-killer MCU" (this reporter's opinion) could be maintained.  Once the GPIO-GPIO connection is broken - you must insure that no pin simply, "floats."  And - when you break that GPIO-GPIO connection - you must insure that you harvest the correct pin.  (yet another unwanted complication)

Hope that you can start as suggested - get the USART to transact w/independent (non-MCU) device.  Then call shortest possible SD access - and see indeed if USART connection, "breaks."  You may then wish to set breakpoints progressively closer to the beginning of SD access code - and zero in on the specific function which "kills" your USART.  (my Red chips all gone - but I'll place tall stack of Black that your System Clock or other "time-altering" code block will reveal...or SD access call "butchered" early/proper USART set-up)

 Hi CB, thank for your great writing, I read all thoroughly also if appeared to me far away my problem but never I miss to read. I am an experienced hardware and software designer from 1975 so the only trouble here is lack of acquanintance with stellaris series. All was working on lm3s9D95 with very minor problem and few issue on FPGA side when DMA is too fast but a good pcb design than wiring, all was clear at LA images of signal propagation... All was at almost done if SILICON remained available... :(( DAMN TI!!!!!

 All design is Linux based and primary porting was at almost done on LM3S, I NEED ETH PHY, so to save effort I was trying to port some code to TM4C if ETH part appear soonest. Again I can abandon all in favour of C2xxx and MSP430/ Freescale or NXP with FPGA supported, I am evaluating wizznet but every ETH chip can serve the purpose.

 The console part was ported on a Sitara as is with all linux support to avoid recode for disappearing silicon, here is a huge FPGA emulating all old obsolete silicon supporting precise timing on hardware. A simple MSP430 serve some peripheral purpose.

 On peripheral side I need ETH to receive command and process timing, C2xxx piccolo series perform all motion and regulation task with some small slaves, TIVA can be a solution smaller but again and  again all WAS working.... :(((((( So the experimental part was to try some small module of project on LM4X TM4C.. but trouble are great than LM3S :(((((

 From your writing:

cb1_mobile said:

Myself/others never liked the 2 "dead shorts" victimizing lunchpad GPIO - so that past compatibility w/vendor's likely "older, M3-killer MCU" (this reporter's opinion) could be maintained.  Once the GPIO-GPIO connection is broken - you must insure that no pin simply, "floats."  And - when you break that GPIO-GPIO connection - you must insure that you harvest the correct pin.  (yet another unwanted complication)

 I subscribe this bad idea, yes I got a broken board, no trouble I bought 4 to be sure to have spare but two day where lost to understand what was wrong before to fully grasp this issue on schematic.. BAD idea, the GPIO are connected to external pin so user if not noticed is aware of that, two resistor 100-300Ohm can be more better and never deaden pin driver.

cb1_mobile said:

Hope that you can start as suggested - get the USART to transact w/independent (non-MCU) device.  Then call shortest possible SD access - and see indeed if USART connection, "breaks."  You may then wish to set breakpoints progressively closer to the beginning of SD access code - and zero in on the specific function which "kills" your USART.  (my Red chips all gone - but I'll place tall stack of Black that your System Clock or other "time-altering" code block will reveal...or SD access call "butchered" early/proper USART set-up)

 Ok, this was done before to write, so I try'd ask for something other opinion and to see if someone has issue with, interface is very simple, few wire and pullup resistors, everything is in place for both test, I can use a more simple interface with just SD socket but no difference.

 Here is also 8664.sd_card.zip this is a slightly modified EKLM4F232 board example. A conditional define is at first lines of include, leave commented and all LCD part is excluded, uncomment and the LCD take place.

 So I can use forever cat commend, LS crash after traversing FS structure, I don't know why, this can be addressed by TI too...

 Trouble come from ROM or SYSCTL call, again I am not so familiar nor with register nor with assembly for ARM, I was so proud to perfrmed better on 68000 when at first accorn presented his Archimede, I liked 88000 from Freescale and successor powerPC too and this is my first ARM deep coding.

 With graph disabled LS crash as you see, cat work forever...

 With graph enabled uart work till SPI initialized... Why??? Forget hardware or not? This moment I have no fast scope nor my Agilent LA so I simply use an saleae logic, good tool but not fast enough to capture glitch or analog trouble where I need joint analysis.

cb1_mobile said:

Suggest we start w/what I believe to be small/simple goal - let's get your USART to continue to work - even after your SD access.  Kindly describe how you test - and thus determine that the USART is working properly.  Beware that attachment of any MCU directly to a "real" RS232 port will likely damage the MCUs RX input.  You must impose a level translator chip or circuit to protect your MCU.  If you could transact w/Hyper Terminal or Tera Terminal - via your USART - we have a good beginning.  Can you manage this?  While this test is simple - fairly easy - my instinct screams that "fix one" will "fix ALL!" 

 Usart is handled onboard from launchpad or again I use a 3.3V interface with RX and TX at cmos level.

 Here is test when LCD is not defined under debugger, no mention on errata:

 Here running unthethered, so something is wrong where??? And here I left my ball, TI has to do some more work on these part that can be great in a future, IMHO LM3S9D was better for me and we can still live with errata too.

 The text is the content of file test.txt, you can access forever if on root of FS never if one level DIR away from root and also CD crash...

 Here LS stand alone, list files then crash and SPI stop working... again WHY??

Thank for all at almost moral support ;)

cb1_mobile said:

Once that USART connection is made and deemed reliable - attempt the shortest possible SD access.  Note then if the USART still is able to perform.  If not - seems most likely that something w/in your SD access code or HW has "disturbed" your USART set-up and/or config.  You may review all of  the key USART Registers while the USART is operational - prior to any SD access.  (best to print these - at that moment)  Then after SD access - again review those same USART Registers - are any changes visible?  If none - check then the set-up/config of each/every USART pin (must switch to GPIO view w/in your IDE) again both before and after SD access.  Again - printout always superior to "memory."  (do not ask how I know...and just where are my damn keys?)

Roberto - understand your frustration, agony - feel your pain...

Have some record of success in design, production, sale & remote diagnosis of hi-tech - and most always success flows from KISS.  (fortunate to have co-founded tech firm - sell like crazy - and then, "go public." - so perhaps - if luck holds - may be somewhat qualified to assist/advise...)

I cannot understand how much (if any) of the quote above you attempted.  As the USART & SD access both appear upon Port_A (your board) - it is likely that SD access may have "be-fouled" your earlier, successful USART set-up/config.  (or somehow altered the baud rate)  Thus - advised that you carefully scan and compare each/every USART Register & related GPIO Register - both before and after - SD Access.  (and print these - for serious/proper/eased side-by-side review!)  Your response was enjoyable - greatly detailed - but silent as regards this basic troubleshooting data harvest & analysis.   Without this - while I remain sympathetic - hoped for, "new tech light" has not dawned - and darkness deepens...

Of course you/clients always want "all things perfect" - but so often our group finds that - like dominoes - first issue toppled - "causes cascade of follow-on solutions!"  It may well be that the solution is surprisingly fast/easy - and the course earlier charted (repeated above) seems logical and impactful.

Kindly perform the detailed test as described.  In addition - as you report only cmos USART levels - with what external device does your USART transact?  And how do you judge correctness of transfer?  Can you - in any way - monitor data and/or signal movement across the USART?  (even if at incorrect baud rate?  Led on TX may serve) 

I do try to be of some help/service to the broad ARM community and trust that the guidelines/practices listed have some, "method to their madness..." 

cb1- said:

Kindly perform the detailed test as described.  In addition - as you report only cmos USART levels - with what external device does your USART transact?  And how do you judge correctness of transfer?  Can you - in any way - monitor data and/or signal movement across the USART?  (even if at incorrect baud rate?  Led on TX may serve) 

 Hi Just tank for all effort, I am suspecting some pattern sensitivity or some rom code error, but this need compare same sw on different silicon, next week I see can be new Launchpad TIVA can ship so I can test on that new silicon what happen. I also can try get some samples but the worst trouble is still NO SILICON available...

 This is at almost full working prototype.... the big trouble is in the top right side, it name LM3S9D9X :(((

 On left you can see Sitara beaglebone in procint of exchanging LM3S board, I recompiled early all project and checked, I got board on friday so next week I can work on it but all console is OK for now.

 Trouble come from peripheral part, I need an ETH enabled part, I am also thinking about NXP, it has a IEE1588 with eth phy on chip available NOW and not when TI decide to die with all us...., Sitara can overcome all this for now...

 So the big board is patched not for now but forever, is so simple if Sitara fail to use everything else board, no space contraint is there....

 On motion part all electronic is moved so I am space constrained and cannot use a lot of chip also power modules are there and not enough space is available...

 This is first attempt to test old LM3S code on new Stellaris LM4S / TIVA TM4C... Stellaris failed miserably, so this is the test bed: Stellaris launchpad an LCD , SD socket, forget Altera board, is just there but never started communication test due to this trouble from parallel test on LCD and remained forever unconnected.

 I upgraded CCS from version 5.2.1 to 5.4 current, no change, when I get TIVA launchpad I can try recompile on that processor to see if problem go away... If yes then ROM aka silicon issue is present.. otherwise can be a pattern sensitivity (again silicon issue)...

 I also printed register images so you can see them, but no wrong setting appear to be in place for me, just direction register set to reflect SPI signals and alternate function again on same pin, USART 0,1 remain selected and nothing change.. USART register remain fully unchanged.. so again my pain about what happen...

 About RX and TX I see pad are available, tomorrow I solder an Header and I plug in the logic LA to see what happen, yes this is a good idea..

 This is the test bed: (remember Altera board is not connected to nothing for now...) Launchpad LCD with an SD socket (just wires and pullups)

Here registers images before LS call

 And after LS call, both GPIOA and USART0

@Roberto:  Really good, detailed data harvest - surely will assist myself/others in analysis - thank you, Roberto.

Have several other "tech fires" to quench today - may be few more hours but I will further review your listing and comment.

Big advantage - our group has a more comprehensive LX4F MCU - but Port_A is configured exactly as is yours.  And I have RS232/RS485 line drivers installed (LTC2870 provides both - in single chip) so that I can easily plug-in to PC COM port.  I've yet to use the SPI pins on Port_A - but will initialize - attempt transfer - and then return to UART and see if it suffers same fate as yours.

Dawns just now that our group most always first develops code w/out interrupts - to quickly/easily test basic functionality.  And - if your code employs interrupts for both UART and SPI - on that same Port_A - does your Port_A Interrupt Handler provide the means to manage interrupts from both SPI and the UART?  Might this be your issue?

Please check your code - and let me know if your SD Access and USART employ the proper SSI0 and UART0 interrupts.  (both may be checked w/in your, "start-up" file - we use IAR which is not the same as yours)   As you've "cut/pasted" code from multiple sources - its very likely that SD Access and USART were not both w/in the same port - in the past.  I may not have the time to delve thru your code today - so if you can respond with interrupt in use (yes/no) for both SD Access and USART - that would be most helpful.

Again - thanks for your effort in providing this most helpful detail...

Update: Have looked at your comparison of Register, "GPIO_RIS" Port_A - and note that this was 0x0000.0002 after UART init - now 0x0000.002F during or post SD Access.  This implies that someway/somehow both UART pins have generated interrupts during or just after your SD Access.  And - all SPI pins but for SSI0RX have also called for interrupt.  Suspect that your interrupt service has become over-whelmed - and doubtful that your SD Access code would handle any/all UART interrupts - and if these are not properly serviced - this may explain your program "hang."

I doubt that your program must manage SD Access and UART together - in near real-time.  Thus - may prove worthwhile to disable your UART interrupts prior to call to SD Access - then complete that SD Access - then disable SD Access interrupts - and finally reenable UART interrupts.  And only then attempt UART access.  (you may have to read this suggestion again to glean its impact.  I don't know how in-depth your interrupt service routines are - or their speed of execution)

Your nicely compiled Register listings does establish that any "contamination" of UART0 settings seems not to have occurred by the call to SD Access.  Thus - my bet now is upon a looping or failed interrupt service - at either (or both) your SPI0 interrupt or UART0 handlers.

It may be possible to (temporarily) bypass the interrupts for SPI0 and UART0 - and see if this restores your system to proper, sequential use operation.  (of SD Access and UART0) 

Hi,

@Roberto, I have read a little bit your program posted in the .zip package - and have two observations - maybe you can check...

1.  You have only SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI0) declaration and no further SSI configurations - no declared pins for that, no speed, no protocol (at least I could not discover these). For some boards with graphical display and SPI interface this initialization is done for the display and is in display driver files; for others no mention. Protocol = MOTO_MODE_3.
2.  In case I missed this, did you formatted the card with the right configuration? - see this thread.

Petrei

Edit:

Never mind, I found where is it initialized....but still worth a check for 2).

@Petrei - thanks for jumping in - Roberto has much time/$/effort invested - we should be able to assist.

To save you/others time/effort - Roberto is able to transact normally w/ UART, SPI and SD card.  But - after SD card access he can no longer transact w/UART.  (other issues as well - but sense is that this is simplest - good place to start!)  

Now both SD card (via SPI) and UART occupy Port_A - his MCU.  Thus my thought that a, "too broad" SD set-up/config "killed" his earlier (proper) UART set-up/config.  I asked that Roberto harvest & present pertinent Register dump - he's complied - yet solution thus far evades...

Perhaps too simple-minded - but a re-initialization of UART post SD Access dawns.  Elegance-lite - but (as sailors say) any Port in a Storm...

 Hi Petrei, my code simply il LM4F232 board with removal of OLED display, so first goal was to have SD working, and you can see from terminal image I can cat a file and have dir list, this has a bug and forever stop at end of listing, this cover point 2 of your hint, I can do some search and in the case do the port of last file system butone thing at time before to do I need have basic I/O working in a stable manner and fully grasp what is wrong... AS I said I am at (may be advanced) beginner level with arm and after learning simple rom usage I got all working as I stated before...

 After having the SD working I added parallel port Kitronix like SD2119 display to do test of basic functionality on LM4F120.

 If you can try help me and have a spare Launchpad you can simply attach the 6 wires needed to access card, just please remove R1 R2 0 Ohm to avoid also brick your board too, zipfile include all of my CCS project, just change library path from softwarehome to adapt your installation and I suppose it can compile, comment or uncomment define of YESLCD clause to enable/disable LCD.

 SO WHY WHY WHY same code work and not??? Again I am suspecting silicon issues or rom trouble about pattern sensitivity, the two register list show SPI enable all port A BIT and initially just UART is selected after all SPI pin are reassigned. DIRection register has no setting for Uart TX pin, is this ok or need set as for MSP and C2xxx?

 Display driver is unidirectional so no difference if it is in place or not, just open terminal and do an LS command to see if it read SD.

 Thank in advance for time and effort.

Finally have made the time to review your code - the only C file I find w/in your zip file is sd_card.c - and it has no initialization (at all) for PA2-PA5 your SPI (that I can find) and only incomplete init for PA0-PA1 UART.  Here's quick cut/paste - pertinent part of sd_card.c w/in main:

    // Set GPIO A0 and A1 as UART.
    //
    ROM_GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);
    //
    // Initialize the UART as a console for text I/O.
    //
    UARTStdioInit(0);

Unless provided w/in UARTStdioInit(0) - you have missed the vital GPIOPinConfig() calls - required both by PA0 & PA1 - setting them as UART0.

And - I find no reference whatsoever for the proper GPIOPinType() and GPIOPinConfig() for any of the SSI0 pins.  So - it must be that other files exist - somewhere - and w/out insight into these - we are, "becalmed - dead in the water!"

With the code provided its doubtful that UART0 or SSI0 could work - unless they default into UART0 & SSI0 modes - and remain w/out variation in those modes.  And - to my mind - relying upon "default behavior" is always w/risk - and condemns your future "cut/paste" into an MCU which does not embody that exact, default behavior.

Roberto - your puzzle pieces are bit scattered for any efficient remote diagnosis.  Your startup_ccs.c file shows NO interrupts beyond the standard MCU "helpers" (NMI, Reset etc.).  And we've learned that a Beagle Board has joined this fray. 

Believe that you can best help yourself by serious, careful review & incorporation of the key set-ups & configs w/in StellarisWare\Examples\Peripherals\ssi\ssimaster.c - this one file details how to set up both UART (PA0/PA1) and SPI (PA2-PA5) - both on your Port A.  Hard to explain how you've missed this - better investigatory techniques will be a great asset to your development. 

My belief is that the SD card is accessed via SPI - any we're not told if you require yet another SPI channel for "something else!"  This all points toward the requirement for greater clarity - will benefit you and your remote crue...

Suspect great time & effort will be required to sort this out - organize - and drive forward...  Factory's "10 foot pole" rule may have some basis - this case...

Cordialement,

cb1

cb1_mobile said:

And - I find no reference whatsoever for the proper GPIOPinType() and GPIOPinConfig() for any of the SSI0 pins.  So - it must be that other files exist - somewhere - and w/out insight into these - we are, "becalmed - dead in the water!"

 Dear CB1, can you explain if this is the trouble why after executing the filesystem MODULE GPIO port 2,3,4,5 appear initialized as you can see from register?

 So do a more deep analysis as mine, if the trouble can be as you state why removing the graph MODULE then the code access the SD card? Register content are the same with working and faiure cases.

 Are you catching the right or the odd?

Hi,

You write:

 So do a more deep analysis as mine, if the trouble can be as you state why removing the graph MODULE then the code access the SD card? Register content are the same with working and faiure cases.

IMHO, I think this could be a stack problem - you have set it at 1K, suggest to increase to 4K since the graphical library and the FAT file system uses many nested function calls. Also try a clean project (import only the source files) - your is a mix of LM4F232 and LM4F120, you can have problems with the debugger.

Regards,

Petrei

@Petrei:

Increasing the stack always worthwhile - and then gradually rolling back.

But - poster repeatedly states that this code ran - very much intact (but for MCU accommodations) on his LM3S board.  (and helpers hostage to such reports...)

Massive detail here (and moving!) - very methodical/piecemeal test/verify best/only means - imho...

Petrei said:

IMHO, I think this could be a stack problem - you have set it at 1K, suggest to increase to 4K since the graphical library and the FAT file system uses many nested function calls. Also try a clean project (import only the source files) - your is a mix of LM4F232 and LM4F120, you can have problems with the debugger.

 Hi Petrej, Thank a lot for hint, was my first idea but stack on analysis was OK and never overflow'd, All code execute but on return from first SD access nor Usart nor SPI work, I can also follow all code and stack never grow more than assigned. There where nothing allocating a so huge space but can simply try set @4k then I can say what happen.

 About LM4F232 where are the reminder of old project? I filtered al out but again IMHO I am not more than advanced beginner.

 I try'd new fresh project for GrDemo project, imported source compile right, binary never load into flash, after a long timeout at 95% say flash timed out...

 I am sure I do some wrong operation on CCS that is a very complex environment, it need long time to fully grasp jointed with documentation reading... Also TIVA series manual are huge too so both variables drive crazy who try to do project porting to another processor... Stellaris series also IMHO suffer of complexity on structure and family was'nt regular on all member.

 Thanks a lot for now...

Petrei said:

at 1K, suggest to increase to 4K since the graphical library and the FAT file syste

 Nope, to be sure of that I increased to 8K but no success, again stack on first deep analysis never growth over few tens of bytes so may be traversing directory.. Leave me check this...

 No change, same errors exactly as when stack was 1K...

@Petrej, where is the LM4F232 reference you see? The file with this name is the low level DIsk I/O and nothing than patch it need, a name change can be less prone to confusing with processor dependance, LM3S never exists so...

Also with GrDemo porting no success, stack was at 256bytes, too small but this has  another issue... I am afraid of all problem arises with this new series, old one suffered from compiler maturity then finally a usable stage, now again trouble over trouble... Changing IDE again can be anightmare but this way I can wait new TM4C and test them...

Gr demo imported over e new fresh project fail with this messages:

Memory Map Initialization Complete
CORTEX_M4_0: Flash Programmer: Timed out while writing to Flash memory
CORTEX_M4_0: GEL: File: /home/roberto/workspace_v5_1/Trainer_1/MyGrlibDemo/Debug/MyGrlibDemo.out: Load failed.

Hi,

@Roberto,

I have examined your project posted several days ago (the .cxxxxxxx files - one reveals the 120 micro, another one the 232 micro) - so I supposed you started with the project for the 232 and then changed some settings to 120. If this is just history maybe it will be no harm - but I was bitten by a project started with configuration for one micro and then changed for another one, so I make a fresh workspace for each micro type - I had difficulties while debugging, compile-link phase was OK (the debugger was unstable). 

Did you tried the same program with another launchpad board?

(Next week I will have an 2G sd card - up to now what I can find is SDXC card sold as SDHC - some problems with the right formatting...).

Petrei

@all

I opened the LM4F232 sd_card example program, and noticed this file mmc-ek-lm4f232h5qd.c. Since, Roberto ported this for LM4F120 launchpad, some changes might be necessary for this file to work with LM4F120 launchpad. Currently, I don't have to time check further.

-kel

Markel Robregado said:

mmc-ek-lm4f232h5qd.c. Since, Roberto ported this for LM4F120 launchpad

 Hi Markel, that file contain low level Disk I/O, on SD card example this is accomplished on SPI mode so on both processor SPI pin are on port A pin 2 3 4 5  and I just left as is, biggest part is pure C coding and the small part dealing with processor specifics is an high level accessing rom or sys library. Are these LIB not uniform across family?

 Used function:

 ROM_SSIDataPut(SDC_SSI_BASE,

 ROM_SSIDataGet(SDC_SSI_BASE,

     /* Switch the SSI TX line to a GPIO and drive it high too. */
    ROM_GPIOPinTypeGPIOOutput(SDC_GPIO_PORT_BASE, SDC_SSI_TX);
    ROM_GPIOPinWrite(SDC_GPIO_PORT_BASE, SDC_SSI_TX, SDC_SSI_TX);
    /* Revert to hardware control of the SSI TX line. */
    ROM_GPIOPinTypeSSI(SDC_GPIO_PORT_BASE, SDC_SSI_TX);
    /* Enable the peripherals used to drive the SDC on SSI */
    ROM_SysCtlPeripheralEnable(SDC_SSI_SYSCTL_PERIPH);
    ROM_SysCtlPeripheralEnable(SDC_GPIO_SYSCTL_PERIPH);

... and so on but all must be independent of platform ... OR NOT???

Please can you show us which kind of adaptation may need this file?

Roberto Romano said:

Memory Map Initialization Complete
CORTEX_M4_0: Flash Programmer: Timed out while writing to Flash memory
CORTEX_M4_0: GEL: File: /home/roberto/workspace_v5_1/Trainer_1/MyGrlibDemo/Debug/MyGrlibDemo.out: Load failed.

 OK, WHen I compiled all code I was using evaluation version, now I am using code limited version, I don't need more onC2xxx nor on MSP side, this error appear if generated size exceed IDE limit. I trimmed two more part and code loaded but doesn't work, again on porting code from LM3S to TIVA this function is needed, no guide where is located so again porting a project is not simple and too much parameter need to be set by hand.

 A more detailed project wizzard can be necessary to link correctly grlib and other part that come from TIVA/Stellaris library otherwise porting or setting the project turn on a nightmare too. Also this error need be addressed correctly, expected code limit exceeded, got a windows like Disk full when printer is not ready....

  At last what about this function:

   //
    // Enable lazy stacking for interrupt handlers.  This allows floating-point
    // instructions to be used within interrupt handlers, but at the expense of
    // extra stack usage.
    //
    ROM_FPULazyStackingEnable();

. is it mandatory? No mention on porting but without call code crash regularly on an instruction has nothing odd.

ROM_GPIOPinTypeSSI(SDC_GPIO_PORT_BASE, SDC_SSI_TX);

After this call a similar call to "ROM_GPIOPinConfigure()" is required.  Confusion stems from Port A defaulting into SPI mode - but once you "repurpose" that default - necessary pin configure setting is most likely lost...

Past - searched for - found - suggested here, "StellarisWare\Examples\Peripherals\spi_master.c - which fully details and provides proper code to initialize both UART and SPI - appearing on Port A.  And indeed confirms the need for GPIOPinConfigure - absent above "corrective" post.

And - one fears this is just the beginning - more massive iceberg remains hidden - beneath the whitecaps...

 Hi CB1, please grasp the project, this stage everything can be ok to get hint, if you read first file where main is in "sdcard.c" a conditional define exist:

#define YES_LCD 1

if this one is commented sdcard can beaccessed and Uart work, when uncommented all graphics library is included and after initialize of SPI both uart and SPI stop working...

 THIS IS NOT A SIMPLE request from a beginner.... Sorry but IMHO CCS for stellaris and also TIVA need to be clean up, I cannot use another compiler due to excessive cost and also setup a chain for GCC can be useful but I also need C2xxx Is not supported for... So I need learn how to migrate cleanly and have RELIABLE code on TIVA..

 LM3S9D was perfect starting from a working project then adding all my code to examples of peripheral usage, this one is very sturdy and doesn't collaborate.

 May be a beginner try more, but this IDE scare me, what about beginners???

 Hi Petrej, at first many thanks to point me about stack, stack was not 1K as you wrote and me too I was sure it was BUT.. it was forever @256bytes...

 To set stack need set property

     -> ARM linker

        -> Set C system stack size

 After this also both graph lib and sd card work together also with 1K size, ok 4K is more better if complex directory structure is in place.

  I signal on proper forum this issue to be addressed about double setting of stack size, may be old one is deprecated but remained in place for compatability :(

 To find it I reset all my ideas and I started read thoroughly all property pages lines and linker output. From output file I found stack was forever @256B so line by line I found that option. :(

 Again this behaviour is dangerous due to debugger working, also my idea to mark stack min into timer and uart IRQ response is not so good....

 I need learn a lot about arm and how to be sure code is fail safe too...

 Thank for now problem solved, I do same for grlibdemo port to see what is wrong, may be a guide on how to can be done from my failure.

GREAT that you persisted - and found (and solved) that portion of your problem.

Unfortunate that early report said stack was checked - and fine.  And as you say - "how really could you know?"

There is such a mix of code - from multiple sources - some not suitable for your newer MCU.  (some call this, "krazy making...")

Good luck - suspect much work still remains...

cb1_mobile said:

Good luck - suspect much work still remains..

 Stack got corrupted before measurement started, IRQ are'nt enabled during Graph initiation and when irq was turned on after stack overflow'd...

 Double setting fooled me as Petrj, and again less than 1024 was ok for me... More than 256 never was a trouble when I was not suspecting tampering the wrong setting....

 These processor exhibit a very strange behaviour, again after deep analysis of what can be wrong on CCS, a good wizard is needed to setup all define like IS_TEMPEST or PART=LM.... Otherwise tampering these define on a fresh project never work and again importing a preset project is the only way to have all correctly setup.

 After that GrDemo porting finally compiled but never init Display, PC get corrupted and stop.... IRQ are disabled, I open a new thread.

 I dislike these processors, I feel them as unreliable, may be CCS or not... Time needed to solve this scenario and have the correct perspective of what happen.

Hi Roberto,

Glad you succeeded - I recognize the tool learning takes time, we all had problems with that. One tip I can give you about the stack - you can estimate the amount needed by generating a listing for each file in the project - each list file (although somewhat hard to read) calculates and writes the stack frame depth for each function - and knowing how your codes operates you can calculate the total stack amount and then take a decision about the size. Of coarse, a real testing is needed, but at least you can start with an estimate rather than guessing with defaults.

Regards,

Petrei

Petrei said:

a real testing is needed, but at least you can start with an estimate rather than guessing with defaults.

 Hi Petrej, thank for hint, that procedure is normal to do for me, also if you read back all thread I say can be when traversing directory structure, from what I traced not more than few tens of stack bytes were needed, so when allocating structure a 3-400 Bytes where needed.  From interrupt monitor of stack growth measurement I never see more than what was expected, IRQ where enabled after stack overflow so was never noticed and max deep remained in the tens of bytes range.....

 The really strange behaviour, sorry for repeating, was why after a stack overflow all returned working correctly other than the USART and SPI, on C2xxx, MSP430, other processor I used and I know in deep I can do some analysis, here I feel a dangerous environment. OK, now I can try connect FPGA and try some deep analysis on code security.

 The missings feature from CCS are the stack analysis and also code size too, on code limited version a more clean error was appreciaetd too.

Markel Robregado said:

 some changes might be necessary for this file to work with LM4F120 launchpad. Currently, I don't have to time check further.

 I Kel, don't waste time, project is OK as is, no change other than stack size on  property dialog are needed. The stack declaration was superseeded by the property so all pain is solved by an IDE feature discovered from map files and digging on settings tab.