 |
 |
| View previous topic :: View next topic |
| Author |
Message |
PeWa
Joined: 15 Jan 2019
Posts: 22
Location: Sweden
|
| "Pointer type do not match" error MMCSD.c and FAT. |
 Posted: Mon Jan 06, 2020 6:35 am |
 |
|
Hello buddies and Happy new year to you all.
I have a strange fault here that I throw out first before I go any further.
First of all the PIC is a 24FJ256GA106 and Compiler is 5.076
When I including these files mmcsd.c and fat.c I got compiler error
first in mmcsd i got "pointer type do not match" here
| Code: |
MMCSD_err mmcsd_read_ocr(int r3[])
{
mmcsd_send_cmd(READ_OCR, 0);
return mmcsd_get_r3(r3); <-------------------here (r3)
}
|
and several "Pointer type do not match" errors in the fat.c file
If I remove fat.c file from the program i cab compile mmcsd.c OK
So there are some error I think with fat.c
Does any one know what this error is before I go in to deep with it.
"Pointer type do not match"
Best regards
Peter |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Mon Jan 06, 2020 7:01 am |
|
|
Unfortunately, that part of the library was written for PIC16/18 chips.
On these, an 'int' is the same size as an 'int8'.
On the PIC24/30/33 this is no longer the case.
The mmcsd_read_ocr function needs to be changed to:
| Code: |
MMCSD_err mmcsd_read_ocr(uint8_t* r1)
{
mmcsd_send_cmd(READ_OCR, 0);
return mmcsd_get_r3(r3);
}
|
The silly thing is it is correct in the function prototypes....
It's actually a 'warning', rather than an 'error', the code will still compile.
However it is better to fix it.
Generally you need to go through fat.c, and every data definition that uses
just 'int', change to use byte, or uint8_t. |
|
|
PeWa
Joined: 15 Jan 2019
Posts: 22
Location: Sweden
|
|
| Posted: Mon Jan 06, 2020 8:55 am |
|
|
Hi Ttelmah
Thank's for reply.
Puhh a lot of changes I have made now.
I have get rid of lot of warnings now but a couple still show up.
I have set Signed int to int8 but how about int16 and int32 are they
also need to be altered ?
Here in this routine the &val is throwing Pointer types do not match
| Code: |
signed int8 fatprintfinfo(FILE* stream)
{
uint8_t ec = 0;
int16 val = 0; // buffer to hold values
char name[MAX_FILE_NAME_LENGTH];
// get name
if(get_file_name(stream->Entry_Addr, name) != GOODEC)
return EOF;
// printf header
printf("\r\n\r\n--");
printf(name);
printf(" Info--");
// printf attributes
ec += mmcsd_read_data(stream->Entry_Addr + 0x0B, 1, &val);
printf("\r\nAttributes: 0x%X", val);
// printf creation date
printf("\r\nCreated: ");
ec += mmcsd_read_data(stream->Entry_Addr + 0x10, 2, &val);
disp_datestamp(val);
printf(" ");
// printf creation time
ec += mmcsd_read_data(stream->Entry_Addr + 0x0E, 2, &val);
disp_timestamp(val);
// printf modification date
printf("\r\nModified: ");
ec += mmcsd_read_data(stream->Entry_Addr + 0x18, 2, &val);
disp_datestamp(val);
printf(" ");
// printf modification time
ec += mmcsd_read_data(stream->Entry_Addr + 0x16, 2, &val);
disp_timestamp(val);
// printf starting cluster
ec += mmcsd_read_data(stream->Entry_Addr + 0x14, 2, (int16*)&val + 1);
ec += mmcsd_read_data(stream->Entry_Addr + 0x1A, 2, &val);
printf("\r\nStarting cluster: %lX", val);
// printf starting address
printf("\r\nStarting address: %lX", cluster_to_addr(val));
// printf size
ec += mmcsd_read_data(stream->Entry_Addr + 0x1C, 4, &val);
printf("\r\nSize: %lu Bytes\r\n", val);
if(ec != GOODEC)
return EOF;
return GOODEC;
}
#endif // #ifndef FAT_PIC_C
|
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Mon Jan 06, 2020 9:41 am |
|
|
On these larger PICs, the default 'int', is a signed int16. Similarly all standard
integers are treated as signed, unless explicitly declared as unsigned.
So 'int32' on a PIC24, is a 'signed int32' on a PIC18. int32 on a PIC18, is
an unsigned int32 on a PIC24. Same for the int16.
This is why I campaign for people to use stdint.h, and the types declared in
this. These are the same whichever processor family you are using...  |
|
|
PeWa
Joined: 15 Jan 2019
Posts: 22
Location: Sweden
|
|
| Posted: Mon Jan 06, 2020 10:52 am |
|
|
Ok
1 thing left then.
I now try to open a file that is created on the SD media Logg.txt
FILE *file_stream;
char filename[] = "Logg.txt";
mmcsd_init();
fat_init();
fatopen(filename,"a", &file_stream); <------------
It gives me an error in the fat.c here
| Code: |
if(set_file(target_file, 0x10, &cur_stream) != GOODEC)
{
cur_stream.Flags |= File_Not_Found;
*stream = cur_stream;
return EOF;
}
depth -= 1;
}
|
That the function is used but not defined , that is strange because it is defined in the top of fat.c
How can this be ?
| Code: |
signed int16 fatopen(char fname[], char mode[], FILE* stream)
{
uint8_t fname_parse_pos = 1; // the current index of the fname character
char target_file[MAX_FILE_NAME_LENGTH]; // temporary buffer to hold names of files
FILE cur_stream; // this will be the stream that will be returned if all goes well
#ifndef FAST_FAT
uint8_t
depth = 0, // how many subdirectories deep the file is
target_file_parse_pos; // the current index of the target_file character
#endif // #ifndef FAST_FAT
// set flags
#ifdef FAST_FAT
switch(mode[0])
{
case 'w':
cur_stream.Flags = Write;
break;
case 'a':
cur_stream.Flags = Append;
break;
default:
return EOF;
}
// start looking for the file, start at root
cur_stream.Start_Addr = cur_stream.Parent_Start_Addr = Root_Dir;
while(fname[fname_parse_pos] != '\0')
{
target_file[fname_parse_pos - 1] = fname[fname_parse_pos];
fname_parse_pos += 1;
}
target_file[fname_parse_pos] = '\0';
// find the file inside of its subdirectory
if(set_file(target_file, 0x20, &cur_stream) != GOODEC)
{
cur_stream.Flags |= File_Not_Found;
*stream = &cur_stream;
return EOF;
}
// at this point, we've found the file
*stream = cur_stream;
return GOODEC;
#else // NO FAST_FAT
switch(mode[0])
{
case 'r':
cur_stream.Flags = Read;
break;
case 'w':
cur_stream.Flags = Write;
break;
case 'a':
cur_stream.Flags = Append;
break;
default:
return EOF;
}
if(mode[1] == 'b')
cur_stream.Flags |= Binary;
// start looking for the file, start at root
cur_stream.Start_Addr = cur_stream.Parent_Start_Addr = Root_Dir;
// figure out how deep we have to go, count how many '/' we have in the string
while(fname[fname_parse_pos] != '\0')
{
if(fname[fname_parse_pos] == '/')
depth++;
fname_parse_pos += 1;
}
// start the fname index at 1 to skip over the '/'
fname_parse_pos = 1;
// open up to the subdirectory, if possible
while(depth > 0)
{
// find the name of our next target directory
target_file_parse_pos = 0;
while(fname[fname_parse_pos] != '/')
{
// check to make sure that we're not at the end of a poorly formatted string
if(fname[fname_parse_pos] == '\0')
return EOF;
// fill up the buffer and increment the indexes
target_file[target_file_parse_pos] = fname[fname_parse_pos];
fname_parse_pos += 1;
target_file_parse_pos += 1;
}
// increment the fname index one more because it's currently pointing at the '/'
fname_parse_pos += 1;
// tack on a \0 to the end of the target file to terminate the string
target_file[target_file_parse_pos] = '\0';
// check to see if the directory exists and open it if possible, otherwise exit because the directory doesn't exist
if(set_file(target_file, 0x10, &cur_stream) != GOODEC)
{
cur_stream.Flags |= File_Not_Found;
*stream = cur_stream;
return EOF;
}
depth -= 1;
}
// check to see if we're trying to open just a directory
if(fname[fname_parse_pos] == '\0')
{
*stream = cur_stream;
return GOODEC;
}
// now that we have the location of the subdirectory that the file is in, attempt to open the file
target_file_parse_pos = 0;
while(fname[fname_parse_pos] != '\0')
{
// fill up the buffer and increment the indexes
target_file[target_file_parse_pos] = fname[fname_parse_pos];
fname_parse_pos += 1;
target_file_parse_pos += 1;
}
// tack on a \0 to the end of the target file to terminate the string
target_file[target_file_parse_pos] = '\0';
// find the file inside of its subdirectory
if(set_file(target_file, 0x20, &cur_stream) != GOODEC)
{
cur_stream.Flags |= File_Not_Found;
*stream = cur_stream;
return EOF;
}
// at this point, we've found the file
*stream = cur_stream;
return GOODEC;
#endif // #ifdef FAST_FAT
}
|
|
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1315
|
|
| Posted: Mon Jan 06, 2020 11:29 am |
|
|
| Usually that means you aren't supplying the right parameter so it is trying to call an overloaded version that doesn't exist. Look at your file stream variable. It is already a FILE * but you are trying to pass it with & which turns it into a FILE **. |
|
|
PeWa
Joined: 15 Jan 2019
Posts: 22
Location: Sweden
|
|
| Posted: Mon Jan 06, 2020 11:50 am |
|
|
Ok I get rid of the Pointer now and it found the function but
| Code: |
FILE file_stream;
char filename[] = "Logg.txt";
mmcsd_init();
fat_init();
fatopen(filename,"a", file_stream);
|
Now I get Error 51 "A numeric expression must appear here" at the place of
file_stream the Fatopen is an pointer stream input.
| Code: |
signed int16 fatopen(char fname[], char mode[], FILE* stream);
|
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Mon Jan 06, 2020 12:57 pm |
|
|
In your previous post you were using:
FILE *file_stream, and then passing with &.
Now you are using FILE file_stream and passing without &.
You need one or the other. Either use a FILE * variable, or pass with &.
One or the other, not both.
Also do you have #device PASS_STRINGS=IN_RAM near the top of
your code?. This is needed to allow a constant string to be passed to
the function as "a". |
|
|
PeWa
Joined: 15 Jan 2019
Posts: 22
Location: Sweden
|
|
| Posted: Mon Jan 06, 2020 1:16 pm |
|
|
Yep I have the
#device PASS_STRINGS=IN_RAM
in top of header file after #include processor defs.
If I set FILE *file_stream to a pointer with *
I get the same error again that the function used but not defined.
If I change to set the address at function with &file_stream but not on the FILE *file_stream.
I get the same error "function used but not defined "so either way
it gives error.
Can it be something with the fat.c that I use on this PIC24 that still gives me the problem I wonder ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Mon Jan 06, 2020 3:02 pm |
|
|
OK.
I've just taken the example ex_fat.c, and changed it to use a PIC24.
Then did a search and replace and replaced all declarations using 'int' (with
white space each side), into 'uint8_t'. Then searched for 'signed uint8_t', and
replaced this with 'int8_t'.
This then gives all standard int declarations changed to uint8_t, and
all that were declared as signed, still as signed.
Does give the warnings about pointer types, but happily compiles. |
|
|
PeWa
Joined: 15 Jan 2019
Posts: 22
Location: Sweden
|
|
| Posted: Tue Jan 07, 2020 3:18 am |
|
|
Hi Ttelmah
I'm on it I included ex_fat , it seems to be conflicts with drivers,
it use fat.c from driver lib, I have compiled it OK but must sort out what happens.
I saw that I could get media Init OK returned 0 , but only on an old 32MB SD card, I have tried FAT16 and 32 but no differ
But if media init is OK does that means that the hardware connections are right? and SPI is UP ?
Even that I have OK for init it can not appendfile (ie open file)
I can check SPI with logic analyser later also.
Will be away for while now and get back for about 9 hours
Thank´s for all help so far. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Tue Jan 07, 2020 3:38 am |
|
|
OK.
Media init, initialises certain variables dependant on what it is reading
from the card. It does not 'error check' what is being read. You need to
look at the variables it has initialised and see if it is making sense of
the values.
The variables are:
Bytes_per_Cluster
FAT_Length
FAT_Start
Root_Dir
Data_Start
In the fat driver, there is a little routine to display the FAT statistics:
disp_fat_stats()
Call this after calling the init, to see what is being read. |
|
|
PeWa
Joined: 15 Jan 2019
Posts: 22
Location: Sweden
|
|
| Posted: Thu Jan 09, 2020 9:44 am |
|
|
Hello again.
I tested the disp_fat_stats() and it showed strange values or same values
on different SD cards so I understand that it could be some wrong with the wiring.
However I also changed the MCU to the example MCU that are in the ex_fat example, PIC18F67J60 and trying the example code that uses the fat.c and mmcsd.c with a little menu system. Just to check my hardware and learn little more about SD card reading/writing.
The ex_fat.c is compiling fine, except the warnings we had before "pointers types do not match".
The program is running and in the fat_init it reports OK
But I can not do any commands it will show error.
But now I have a easier system with PIC18 to test this on now.
I putted in the disp_fat_stats after the init in this working program and that showed same result also on different cards so i think that this is why it does not work.
I have hooked up SPI analyser also so I can check lines and what I can see right now is that the SDO line from SD card is not sending any data only SDI and clock and CS is working.
So I have to investigate this little more, Data I/O has been working before
in some other code I tested so it is something in the default driver/program. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9097
Location: Greensville,Ontario
|
|
| Posted: Thu Jan 09, 2020 10:29 am |
|
|
| OK, basic Hardware questions.... What voltage is the PIC VDD and what interface is between PIC and SD card ? |
|
|
dluu13
Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON
|
|
| Posted: Thu Jan 09, 2020 12:22 pm |
|
|
One of the first things to try is to read the sticky thread in the code library about mmcsd.c and fat.c to fix the library (MBR fix) and the sticky thread about SD card in the General CCS C Discussion forum.
If you want to see if it's the hardware, one of the things you can try is to directly use functions from mmcsd.c rather than trying to use the FAT filesystem. One quick thing to check is if you get good results from mmcsd_print_cid() and mmcsd_print_csd().
Then, you can format the card to all zeros, and then start to write known numbers into memory locations that you define. Use a hex editor like HxD on your PC to view the data and make sure that you actually wrote what you expected.
If these all work as expected then it's probably something to do with the FAT code rather than your hardware.
A good resource for SD card if you want to read further is http://www.elm-chan.org/. Wikipedia is also pretty good.
Personally, I was never able to get the CCS FAT/SD card drivers working and I ended up buying the Brush Electronics driver. It does cost a bit, but it's easy to use and the author (asmallri on this forum) is responsive to questions. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
