Matrix user forums

Hi folks,

I have a simple application based upon the example "simple slow datalogger" flowchart using a PIC18f4455 on an EB006, with an LCD module (EB005) connected to Port B and an SD/MMC card reader (eb037) connected to Port A. I also have an analogue source derived from the potentiometer of the Elektor experiment module fed in directly to RA0/AN0 to act as the data source.

I am using Flowcode version 4.3.7.63 (professional) with the corrected FAT16.c file. The memory card in use is a Sandisk 32Mib MMC card formatted with 512 byte sectors and is blank.

The jumper blocks are set as follows

MMC reader
Connector block = "A" and System (J4) = "+5v"

LCD module
Connector block = "Default"

As I say, the programme is based upon the example "5 simple slow datalogger" for the EB037 but with the ECIO replaced with the PIC18F4455 on the EB006 and the configuration words adjusted accordingly (see attached files). initially when I compiled the project to the chip, all I got was "waiting for card" on the LCD display. So I added a section to the initialise card loop to display a progress bar. Now I can see that the processor is still active because the progress bar still animates but the programme is still waiting for the card to go active. Any suggestions?

Robin

Hello,

I have compared your C code file to the file that my Flowcode is creating and you seem to be using a much older version of the FAT component code. Attached is the up to date component. Simply drop it into your "Flowcode v4/Components" directory and then start Flowcode.

You may also want to check that none of the component macros have been customized using the custom code feature.
You can also print out the return value in the main startup loop to see whats going wrong. Some common problems include the following.

#define MX_ERR_NOCARD 255
#define MX_ERR_NORESP 254
#define MX_ERR_NOACK 253
#define MX_ERR_TOUT 252
#define MX_ERR_RESERVED 251
#define MX_ERR_BAD 250
#define MX_ERR_FREE 240
#define MX_ERR_FILENOTFOUND 239
#define MX_ERR_ROOTFULL 238
#define MX_ERR_SECTBYTES 237

Thanks for the reply Ben,

I put the new Pic_fat16.c file in the right place and the .c file was some bit bigger than before but the program still did not work - a quick modification to the program to display the error number gives code 255 (no card). As far as I know, there is no custom or supplementary code in the project file ("use supplementary code" is unchecked and all the "customized" entried in the "customized component code" dialog read "false"). There is one slight anomaly in my set-up in that I cannot get the latest version of PPP to work properly (see my other post in the Flowcode V4 forum re PIC18F26J50). I have managed to roll back to the version that is on the flowcode install media in a parallel installation (a second install in an alternative location).

The generated project .c file is attached.

I have also tried with a formatted SD card with the same end result.

Any thoughts gratefully appreciated.

Robin

One additional question ... should the extended CPU functionality be enabled or disabled?

Hello,

Extended CPU can create problems so it is recommended to disable it. Ill have a think on it and see if I can work out whats going wrong for you.

Thanks Ben,

That's what I found when completing the Elektor microcontrollers course - so it was disabled by default in my setup. I did try enabling it last night but it made no difference - the application worked as before.

Ben:

Further information for your deliberations. I got my trusty (very) old analogue oscilloscope out and had a look around the signals being sent to the memory card and have discovered (I had to reduce the delay in the waiting for car loop to 10ms - so I am not expecting anything to work ... this was just to see what the signals are doing) the following:-

CS (RA2) is a high going pulse approximately 320uS wide and is presented to the chip as 0v idle and 3.3v active.
CLK (RA3) is a series of high going pulses approximately 20-30uS wide lasting approximately 600uS and have the same voltage properties as CS (during the SDO pulse the clock activity appears to reduce)
SDI (RA4) appears to be low (0v) with no signals at all
SDO (RA5) appears as a low going pulse approximately 160uS wide and 20uS after CS has gone high. The signal idles at 3.3v but the low portion is no lower than 0.8v

Does any of that help?

Robin

More information:

I finally found the PIC16f877 I got with the Elektor course and tested the EB037 using the precompiled test programme. The results for the three types of SD / MMC cards that I have were as follows

Sandisk 32MiB MMC "Reset failed > MMC failed"
BluBox 1GiB SD "Reset failed > MMC failed"
Crucial 1GiB SD "Reset success > MMC failed"

As a little test, I pressed on the MAX buffer chip while the test was ongoing and with the Blubox card (only) the test sometimes gets right the way through to "read failed" or "MMC write: error" and even on one occasion it got all the way through to "successful" ... it seems to depend how I pressed the chip.

As I am now positively confused, any help would be gladly appreciated! Could the EB037 be faulty? Could it be the cards?

Just so other users know, I have asked for the board to be returned to us for testing.

Benj,

Is there any news on this issue? I seem to have the same problem with my EB0038. As did RobinCordell I too applied a little pressure to the MAX3002 (bending the PCB a little) and that seem to cause the test to succeed. So can you update us with any information?

Regards
Cthulhu

Hello,

I take it you mean a EB037 and not the EB038 as this does not include the MAX chip.

We always test 100% of our boards before they are released but in some rare instances a dry joint or board damage such as over flexing a circuit board can cause a misconnection. If you have such a board under warranty (eg you can prove with a receipt that its under 1 year old) then we will take the board back and fix it for you. Otherwise if the board is out of warranty you can use a soldering iron and some soldamop or other braided wire to try and reconnect any misconnected pins. I would always test the pins for connectivity first using a multimeter just to ensure there is a fault in the connection. Over 80% of the returns I get are actually working perfectly and I rarely get returns.

Yes, i meant the EB037 (a little typo from my side). I was just curious if you received the board that you asked for and was able to detect what the problem was. I'm a senior embedded software engineer who's just starting to fiddle with micro controllers and as such am an electronics novice. My board is less than 1 year old and I'm wondering if I should send it back for diagnostics. I'm pretty sure that all is connected as should be (I have no problems with other e blocks like the EB003, EB005 or EB056).
Maybe if RobinCordell is still on the forum he can share with us what his findings are?