I'm working on a Texas Instruments DSP (TMS320F2812).
With my actual soft (C language), I can read information on SD card (<= 2GB). But when I try with a 4GB card, it doesn't works.
I readed a lot of documents, and I know there are many differences between this 2 kind of cards (FAT16, FAT32,...)
But my first problem appears when I send CMD0 ; normally it's :
- 0 1(Start bit) 0 0 0 0 0 0
I attach two pictures :
- The first on when I send CMD0 on a 2GB card
- The second one when I send CMD0 on the 4 GB card.
With the same software, the frame is not the same ; do you know where does the problem comes from?
Excuse for my poor English, I'm French.
Regards,
I realize something ; problem doesn't comes from CMD0. The 2 cards (2GB & 4GB) accept this command.
Problem comes from the following command, CMD8.
I send CMD8, with arg 0x1AA, but I never have answer 0x1AA. I don't know which answer I received.
Can the low capacity cards (<2GB) accept this command?
CMD0 --> CMD8 -->CMD55 --> ACMD41
Because this is the only way to initialize SDHC card, isn''t it?
Regards,
Related
I'm just creating an app(kivy) for a raspberry pi(3b) with 7 inch touchdisplay. In addition I implemented a light sensor (TSL2591), which can regulate the brightness of the backlight using following command:
os.system('sudo sh -c "echo '+str(brightness)+' > /sys/class/backlight/rpi_backlight/brightness"')
with values of brightness 0 to 255
Works fine so far, but I do update the brightness once a second. If I'm not wrong, the command overwrites a config file and I mind of write access to the SD Card that often. I think the SD card will be corrupt after a short period of time.
For sure I can try to get less write operations, but it also leads to less smoothness:
update slower than 1 sec
only write if brightness value really changes
don't use all of the 255 steps
So the main question is: is there any other way to control the brightness? Or any workaround? I could not find a "real" Datasheet or any other advice on the internet. So maybe there is another way.
That's not a conventional disk file; it's a "device special file" which the kernel artificially creates to look like a disk file. It allows you to "talk" to device drivers using standard read() and write() calls.
You need not worry about SD card wear.
this will be my first time asking a question. First of all, I am just a programmer, I don't know much about electronics.
I am trying to communicate with a MCP9880 temeprature sensor through i2c, but I am getting weird readings in between 'real' ones, output looks like this (in decimal):
0 29
255 255
128 0
0 29
255 255
255 255
Here the 'real' lecture would be 128 0, but normally I get either 0xff or 0x1D as you can see. This happens reading any register. Also, other i2c devices are working as expected, but the many MCP9808 that we tried keep the same behaviour. Here's the code I use to read the temperature register (in bascom, I'm forced to use it :( )
I2cstart 'StartI2C.
I2cwbyte Wr_sensor1 'MCP9808 addr.
I2cwbyte &H05 'Temperature register
I2cstart 'StartsI2C.
I2cwbyte Rd_sensor1 'MCP9808 addr
I2crbyte Temp_1621 , Ack 'Read first byte
I2crbyte Temp_1621_dec , Nack 'Read second byte
I2cstop
The addresses are checked and correct, and I really think the code should be right. I keep saying this is an electronics issue, but keep saying they checked and everything is allright.
Thanks in advance.
PS: Here's a link to the datasheet http://ww1.microchip.com/downloads/en/DeviceDoc/25095A.pdf
Ok, I found the answer. Doing further tests, the device acted as if it resetted itself all the time. I suspected tiny voltage drops, so I researched the topic, plugged a capacitor, and that was it!
I hope this can help somebody :)
I'm using a STM32F401VCT6U "discovery" board, and I need to provide a way for the user to write addresses in memory at runtime.
I wrote what can be simplified to the following function:
uint8_t Write(uint32_t address, uint8_t* values, uint8_t count)
{
uint8_t index;
for (index = 0; index < count; ++index) {
if (IS_FLASH_ADDRESS(address+index)) {
/* flash write */
FLASH_Unlock();
if (FLASH_ProgramByte(address+index, values[index]) != FLASH_COMPLETE) {
return FLASH_ERROR;
}
FLASH_Lock();
} else {
/* ram write */
((uint8_t*)address)[index] = values[index]
}
}
return NO_ERROR;
}
In the above, address is the base address, values is a buffer of size at least count which contains the bytes to write to memory and count the number of bytes to write.
Now, my problem is the following: when the above function is called with a base address in flash and count=100, it works normally the first few times, writing the passed values buffer to flash. After those first few calls however, I cannot write just any value anymore: I can only reset bits in the values in flash, eg an attempt to write 0xFF to 0x7F will leave 0x7F in the flash, while writing 0xFE to 0x7F will leave 0x7E, and 0x00 to any value will be successful (but no other value will be writable to the address afterwards).
I can still write normally to other addresses in the flash by changing the base address, but again only a few times (two or three calls with count=100).
This behaviour suggests that the maximum write count of the flash has been reached, but I cannot imagine it can be so fast. I'd expect at the very least 10,000 writes before exhaustion.
So what am I doing wrong?
You have missunderstood how flash works - it is not for example as straight forward as writing EEPROM. The behaviour you are discribing is normal for flash.
To repeatidly write the same address of flash the whole sector must be first erased using FLASH_EraseSector. Generally any data that needs to preserved during this erase needs to be either buffered in RAM or in another flash sector.
If you are repeatidly writing a small block of data and are worried about flash burnout do to many erase write cycles you would want to write an interface to the flash where each write you move your data along the flash sector to unwriten flash, keeping track of its current offset from the start of sector. Only then when you run out of bytes in the sector would you need to erase and start again at start of sector.
ST's "right way" is detailed in AN3969: EEPROM emulation in STM32F40x/STM32F41x microcontrollers
This is more or less the process:
Reserve two Flash pages
Write the latest data to the next available location along with its 'EEPROM address'
When you run out of room on the first page, write all of the latest values to the second page and erase the first
Begin writing values where you left off on page 2
When you run out of room on page 2, repeat on page 1
This is insane, but I didn't come up with it.
I have a working and tested solution, but it is rather different from #Ricibob's answer, so I decided to make this an answer.
Since my user can write anywhere in select flash sector, my application cannot handle the responsability of erasing the sector when needed while buffering to RAM only the data that need to be preserved.
As a result, I transferred to my user the responsability of erasing the sector when a write to it doesn't work (this way, the user remains free to use another address in the sector to avoid too many write-erase cycles).
Solution
Basically, I expose a write(uint32_t startAddress, uint8_t count, uint8_t* values) function that has a WRITE_SUCCESSFUL return code and a CANNOT_WRITE_FLASH in case of failure.
I also provide my user with a getSector(uint32_t address) function that returns the id, start address and end address of the sector corresponding to the address passed as a parameter. This way, the user knows what range of address is affected by the erase operation.
Lastly, I expose an eraseSector(uint8_t sectorID) function that erase the flash sector whose id has been passed as a parameter.
Erase Policy
The policy for a failed write is different from #Ricibob's suggestion of "erase if the value in flash is different of FF", as it is documented in the Flash programming manual that a write will succeed as long as it is only bitreset (which matches the behavior I observed in the question):
Note: Successive write operations are possible without the need of an erase operation when
changing bits from ‘1’ to ‘0’.
Writing ‘1’ requires a Flash memory erase operation.
If an erase and a program operation are requested simultaneously, the erase operation is
performed first.
So I use the macro CAN_WRITE(a,b), where a is the original value in flash and b the desired value. The macro is defined as:
!(~a & b)
which works because:
the logical not (!) will transform 0 to true and everything else to false, so ~a & b must equal 0 for the macro to be true;
any bit at 1 in a is at 0 in ~a, so it will be 0 whatever its value in b is (you can transform a 1 in 1 or 0);
if a bit is 0 in a, then it is 1 in ~a, if b equals 1 then ~a & b != 0 and we cannot write, if bequals 0 it's OK (you can transform a 0 to 0 only, not to 1).
List of flash sector in STM32F4
Lastly and for future reference (as it is not that easy to find), the list of sectors of flash in STM32 can be found on page 7 of the Flash programming manual.
I got this error on a CJ1W-CT021 card. It happen all of a sudden after its been running the program for some time. How i found it was by going to the IO Table and Unit Set up. Clicked on parameters for that card and found two settings in red.
Output Control Mode and And/Or Counter Output Patterns. This was there reading
Output Control Mode = 0x40 No Applicable Set Data
And/Or Counter Output Patterns = 0x64 No Applicable Set Data
no idea on how or why these would change they should of been
Output Control Mode = Range Mode
And/Or Counter Output Patterns = Logically Or
I have added some new code, but nothing big or really even used as i had the outputs of the new rungs jumped out. One thing i thought might cause this is every cycle of the program it was checking the value of an encoder connected to this card. Maybe checking it too offten? Anyhow if anyone has any idea what these do or how they would change please post.
Thanks
Glen
EDIT.. I wanted to add the bits i used, dont think any are part of this cards internal io but i may be wrong?
Work bits 66.01 - 66.06 , 60.02 - 60.07 , 160.12, 160.01 - 160.04, 161.02, 161.03
and
Data Bits (D)20720, 20500, 20600, 20000, 20590, 20040
I would check section 4-1 through 4-2-4 of the CT021 manual - make sure you aren't writing to reserved memory locations used for configuration data of the CT021 unit.
EDIT:
1) Check Page 26 of the above manual to see the location of the machine switch settings. The bottom dial sets the '1's digit and the top dial sets the '10's digit (ie machine number can be 0-99);
2) Per page 94, D-Memory is allocated from D20000 + (N X 100) (400 Words) where N is equal to the machine number.
I would guess that your machine number is set to 0 (ie: both dials at '0'), 5, or 6. In the case of machine number '0', this would make the reserved DM range D20000 -> D20399. In this case (see pages 97, 105) D20000 would contain configuration data for Output Control Mode (bits 00-07) and Counter Output Patterns (bits 08-15). It looks like you are writing 0x6440 to D20000 (or D20500, D20600 for machine number 5 or 6, respectively) and are corrupting the configuration data.
If your machine number is 0 then stay away from D20000-D20399 unless you are directly trying to modify the counter's configuration state (ie: don't use them in your program!).
If the machine number is 1 then likewise for D20100-D20499, etc. If you have multiple counters they can overlap ranges so they should always be set with machine numbers which are 4 apart from each other.
I am using a Omron PLC and looking at this bit in memory
CIO1767 BIT 14 In binary view
Its either going to be a 1 (on) or 0 (off)
I would like to put in the ladder logic. If this bit is on do ....
But Dont know how to write that bits address.
First do i have to use a compare to see if its 1 or 0
or
can i do a normally open and it give me NC if its 0?
Also if unclear, how do i write this bit i was trying CIO1767.14 but that does not seem to work?
thanks
glen
Figured it out, You can use a NO or NC operation. For this instance you have to place the operation, then for address just put CIO . Then it will give you another pop up asking for the data or location here you would put 1767.14. Thats it!