View AN4125_8186663.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

june 2012 doc id 023297 rev 1 1/15 AN4125 application note how to manage simultaneous i2c and rf data transfers with the m24lrxxe-r introduction the m24lrxxe_r is an eeprom device designed to be ac cessed via two different interfaces: a wired i2c interface and a standard contactless iso 15693 rfid interface. figure 1. typical applic ation of an m24lrxxe_r dual interface eeprom st has published various supporting application notes explaining how the rf interface works and the basic principles of passive rf id technology. these documents are available from: www.st.com/dualeeprom . the possibility of using two diff erent interfaces to control the dual-inter face eeprom implies two host controllers: a microcontroller with an i2c bus and an iso 15693 rfid reader. due to their nature, these two host controllers are not synchronized, which means that both controllers might try to access the m24lrxxe_r concurrently. to manage this kind of situation, the m24lrxx e_r has a built-in circuitry able to handle possible concurrent communications and powering activities from the rf and i2c sides. this application note describes how the m24lrxxe_r arbitration circuitry operates. it applies to the products listed in ta b l e 1 . table 1. applicable products type part numbers memory products m24lr04e-r, m24lr16e-r, m24lr64e-r -36 3$! 3#, !pplicationmaster !pplicationboard )#bus )#bus )3/2& )3/2& .-3yy&@3 www.st.com
contents AN4125 2/15 doc id 023297 rev 1 contents 1 rf - i2c arbitration mechanism description . . . . . . . . . . . . . . . . . . . . . . 5 1.1 communications and power supply conditions . . . . . . . . . . . . . . . . . . . . . 5 1.2 communication arbitration when the rf and i2c channels are both active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2.1 i2c busy states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2.2 rf busy states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2.3 arbitration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2 recommendations when developing the m24lrxxe_r application software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1 issuing a command through the i2c channel . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.1 i2c request while the rf channel is busy . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.2 i2c requests and rf time slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.3 an i2c request was interrupted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2 issuing a command through the rf channel . . . . . . . . . . . . . . . . . . . . . . 13 3 revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
AN4125 list of tables doc id 023297 rev 1 3/15 list of tables table 1. applicable products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 table 2. four possible combinations of power supply sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 table 3. possible cases of communication arbitration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 table 4. m24lrxxe_r status according to command and v cc supply . . . . . . . . . . . . . . . . . . . . . . 13 table 5. document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
list of figures AN4125 4/15 doc id 023297 rev 1 list of figures figure 1. typical application of an m2 4lrxxe_r dual interface eeprom . . . . . . . . . . . . . . . . . . . . . 1 figure 2. i2c read command busy state. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 figure 3. i2c write command busy state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 figure 4. rf read command busy state. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 figure 5. rf write command busy state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 figure 6. rf stay quiet command busy state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 figure 7. example of an inventory command where the m24lrxxe_r is decoded in slot 13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 figure 8. i2c polling when the rf channel is processing a command . . . . . . . . . . . . . . . . . . . . . . . . . 9 figure 9. m24lrxxe_r state transition diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 figure 10. optimal hardware schematic of an m24lrxxe_r application . . . . . . . . . . . . . . . . . . . . . . 12
AN4125 rf - i2c arbitration mechanism description doc id 023297 rev 1 5/15 1 rf - i2c arbitration mechanism description the m24lrxxe_r arbitration circuitry is twofold. it contains: a power management unit that handles the power coming potentially from the rf or the i2c side a communication arbitration unit that tackles potential concurrent communications from the rf and the i2c sides 1.1 communications and power supply conditions the power supply management unit has been designed to a llow for flexibility, especially when both the rf power and the wired power line are active at the same time. the basic principle is: when supplied only from the rf side: ? the m24lrxxe_r can be accessed only by the rf reader when supplied from both the v cc pin and the rf field: ? the m24lrxxe_r will serve the first decoded command (either rf or i2c) and will not decode any command from the other interface (either i2c or rf) until the first decoded command is complete. table 2. four possible combinations of power supply sources possible cases v cc rf field actions case 1 0 v or not connected off the m24lrxxe_r is reset. case 2 0 v or not connected on rf data transfers: yes i2c data transfers: no case 3 on (1) 1. v cc is ?on? when the value is between v cc min and v cc max. please refer to the m24lrxxe_r datasheet for full details. on rf data transfers: yes i2c data transfers: yes (see section 1.2: communication arbitration when the rf and i2c channels are both active for details). case 4 on (1) off rf data transfers: no i2c data transfers: yes
rf - i2c arbitration mechanism description AN4125 6/15 doc id 023297 rev 1 1.2 communication arbitration when the rf and i2c channels are both active arbitration depends on whether the i2c and rf channels are in the busy state. section 1.2.1 and section 1.2.2 give the definitions of the i2c and rf busy states, respectively. 1.2.1 i2c busy states when decoding an i2c read command, the m24lrxxe_r is in the i2c busy state from the start condition until the stop condition. figure 2. i2c read command busy state when decoding an i2c write command, the m24lrxxe_r is in the i2c busy state from the start condition until the comp letion of the write cycle (trigg ered by the stop condition). figure 3. i2c write command busy state 1.2.2 rf busy states in most cases, an rf command is defined as a received request initiated by the sof (start of frame) and terminated by the decoding of the eof (end of frame) of the response frame. rf commands can be gathered into several groups: read command group when decoding an rf read command, the m24lrxxe_r is in the rf busy state from the sof (start of frame) of the request frame until the eof (end of frame) of the response frame. the figure below shows the rf busy state of commands in the read group. figure 4. rf read command busy state s t a rt re a d comm a nd s top i2c bus y a i17 33 9 s t a rt write comm a nd s top i2c bus y a i17 3 40 write cycle s of re qu e s t eof rf bus y a i17 3 41 re s pon s e s of eof
AN4125 rf - i2c arbitration mechanism description doc id 023297 rev 1 7/15 commands in the rf read command group are: read block, fast read single block, read multiple blocks, fast read multiple blocks get system info select reset to ready get multiple block security status initiate, fast initiate inventory initiated write command group when decoding an rf write command, the m24lrxxe_r is in the rf busy state from the sof (start of frame) of the request frame until the eof (end of frame) of the response frame. write commands include a write cycle t w . the figure below shows the rf busy state of commands in the write group. figure 5. rf write command busy state commands in the rf write command group are: write block write afi, lock afi write dsfid, lock dsfid write-sector password, lock-sector password, present-sector password stay quiet command the stay quiet command is the only command defined as a single request frame (not followed by a response frame). the m24lrxxe_r is in the rf busy state during the whole [sof ?. eof] sequence as shown in the figure below. figure 6. rf stay quiet command busy state inventory command an inventory command is used when several m24lrxxe_r devices are inside the range of the same rf electromagnetic field. when the inventory command scans 16 slots, the m24lrxxe_r is in the rf busy state from the sof (start of frame) of the request frame until the eof (end of frame) of the response frame. note: the addressed m24lrxxe_r device might stay a long time in the rf busy state if it is decoded during the last (16 th ) time slot. s of re qu e s t eof rf bus y a i1750 3 re s pon s e s of eof write cycle t w s of re qu e s t eof rf bus y a i17504
rf - i2c arbitration mechanism description AN4125 8/15 doc id 023297 rev 1 figure 7. example of an inventory command where the m24lrxxe_r is decoded in slot 13 1.2.3 arbitration when both interfaces are active (as defined in case 3 in table 2: four possible combinations of power supply sources 1), the m24lrxxe_r decodes and executes the first received command, as detailed in table 3: possible cases of communication arbitration . s of re qu e s t eof rf bus y a i17505 eof eof re s pon s e eof s lot 1 s lot s 2 to 12 s lot 1 3 table 3. possible cases of communication arbitration initial state event m24lrxxe_r action m24lrxxe_r is in the i2c busy state: v cc active and an i2c command is being decoded or executed rf command transmitted during an i2c command rf command is not decoded m24lrxxe_r is in the rf busy state: an rf command is being decoded or executed v cc active and i2c command transmitted during an rf command i2c command is not decoded
AN4125 recommendations when developing the m24lrxxe_r application software doc id 023297 rev 1 9/15 2 recommendations when developing the m24lrxxe_r application software the application software has to take into account that a command might not be executed if the other channel (i2c or rf) is already processing a command. the application software should therefore check the m24lrxxe_r busy status before sending a command. 2.1 issuing a command through the i2c channel 2.1.1 i2c request while the rf channel is busy if the m24lrxxe_r is processing a command from the rf channel, no command issued on the i2c bus will be executed, therefore none of the bytes tr ansmitted on the i2c bus will be acknowledged (noack). this information can be considered as the rf busy state (a) and the application?s i2c software should include a polling loop on the rf busy state (with a timeout limit) when issuing a command on the i2c bus. in this way, the i2c command can be completed once the rf command under process has completed. figure 8. i2c polling when the rf channel is processing a command a. in the same way as during an internal writ e cycle, the m24lrxxe_ r is ?busy? during t w (please refer to the m24lrxxe_r datasheet for more details about the polling loop during t w ). -36 2&command inprogress 3tartcondition $eviceselect with27 !#+ returned 9%3 ./ $ataforthe 7riteoperation $eviceselect with27 3endaddress andreceive!#+ &irstbyteofthe )#command with27bit is nowdecodedbythe -,2xx% 2 9%3 ./ 3tart condition #ontinuethe 7riteoperation #ontinuethe 2andom2eadoperation
recommendations when developing the m24lrxxe_r application software AN4125 10/15 doc id 023297 rev 1 important it is paramount to exactly carry out the i2c polling sequence described in figure 8 in order to keep the m24lrxxe_r in a constant i2c busy state. right method: once the device select is acknowledged, the i2c command starts executing until full completion, that is, until the transmission of the stop condition which ends the command (or at the end of the write cycle t w , for a write command). wrong method: looping on the device select until it is acknowledged, sending a stop condition and then initiating a new i2c command: this is inadequate as an rf request might have been served between [ack] and the new i2c command (time slot during which the m24lrxxe_r is not in the i2c busy state. note: if the application is disturbed by too great a number of decoded rf commands, it might be convenient that the i2c bus master prompts the application to stop rf requests so that the i2c bus can access the m24lrxxe_r. 2.1.2 i2c requests and rf time slots application software management in most cases, the application fully controls the i2c bus. on the other hand, it cannot always predict rf commands. to have a robust app lication, the m24lrxxe_r should be fullly controlled through the i2c bus, that is, the application master has to: 1. determine when the i2c commands have to be transmitted 2. determine the time slots during which rf transfers may be processed the reason for this is that rf commands might not be properly transmitted (for example, if the m24lrxxe_r leaves the rf field). the i2c bus master has to prevent this from happening by applying the following rules: the master determines when the i2c commands have to be transmitted the master delivers the supply voltage (through one of its i/os) to the m24lrxxe_r?s v cc pin only when an i2c data transfer is under way the master determines the rf time slots the master stops supplying (i/o in hiz) the m24lrxxe_r through its v cc pin upon completion of the i2c data transfer. rf transfers are processed more safely when the v cc pin is not supplied, because: ? if the decoded rf command is correct, it is executed (no need to supply power through the v cc pin) ? if the rf command is truncated (m24lrxxe_r is outside the rf field), the m24lrxxe_r is reset (power-off state, see figure 9 ).
AN4125 recommendations when developing the m24lrxxe_r application software doc id 023297 rev 1 11/15 figure 9. m24lrxxe_r state transition diagram 1. the m24lrxxe_r returns to the power off state if the tag is out of the rf field for at least t rf_off . ai06681b power-off in field out of field ready quiet selected any other command where select_flag is not set stay quiet(uid) select (uid) any other command any other command where the address_flag is set and where inventory_flag is not set stay quiet(uid) select (uid) reset to ready where select_flag is set or select(different uid) reset to ready out of rf field after t rf_off out of rf field after t rf_off after t rf_off
recommendations when developing the m24lrxxe_r application software AN4125 12/15 doc id 023297 rev 1 application hardware architecture the application master should control the i2c bus lines and the power supply line so as to keep full control of the m24lrxxe_r. figure 10 shows a typical hardware schematic. figure 10. optimal hardware schematic of an m24lrxxe_r application this type of hardware architecture is optimal in applications where power saving is a key feature (like portable applications supplied from a battery). the supply voltage can be directly delivered to an ultralow power microcontroller (for instance the stm8l, information available from http://www.st.com/mcu/ ). this implementation makes it possible to keep the application supply current in the 1 a range (value of the stm8l supply current when in the active-alt mode) and: the application saves power when in the standby mode, as the battery does not supply the standby current to the m24lrxxe_r (40 a) nor the current through the sda pull- up resistor the application controls the m24lrxxe_r in a safe mode (the v cc pin is supplied by the master only when an i2c request is being processed) 2.1.3 an i2c request was interrupted a start condition defines the i2c channel as busy until the completion of the i2c command (stop condition) or until i2c timeout. if for some uncontrolled reason, inadvertent unterminated instructions are sent to the i2c bus, the m24lrxxe-r features a timeout mechanism that automatically resets the i2c logic block. the i2c busy state is reset either: by decoding a device select byte different from 1010 xxxxb, by decoding a stop condition, by the completion of the internal write cycle (t w , triggered by a decoded write instruction), or after timeout. the best way for the i2c bus master to clear a spurious busy state is to periodically issue a [start+stop] sequence. note: in noisy applications, st recommends to implement the ?9 start + 1 stop? sequence described in an1471 (available from the st website: www.st.com). -36 )/ 3$! 3#, 6 ## 6 33 m24lrxxe-r )#bus -aster #n& 2 7 6 bat "attery 2 pull up !pplicationmaster 2 pull up
AN4125 recommendations when developing the m24lrxxe_r application software doc id 023297 rev 1 13/15 2.2 issuing a command through the rf channel case 1: the m24lrxxe_r is processing an i2c command if the m24lrxxe_r is processing a command from the i2c channel, no command issued on the rf channel will be executed (the rf command will not pr ovide any response) when the m24lrxxe_r is i2c busy. the application?s rf software should include an ?i2c busy po lling loop? (including a timeout as there might not be a response) when issuing an rf command. in this way, the rf command is always correctly executed once the i2c commands under execution are completed. case 2: the m24lrxxe_r application is powered on the first condition for a safe design of an m24lrxxe_r application is that all the sensitive data stored in the m24lrxxe_r memory are protected with rf passwords, so that a spurious rf command could not modify these data. the second condition for a safe application design is that the application master fully controls the m24lrxxe_r. we know that, as explained in section 2.1.2 , if the v cc pin is not supplied, and the rf field drops to zero while the m24lrxxe_r is decoding an rf command, then the m24lrxxe_r is reset. this means that the master has to supply the m24lrxxe_r?s v cc pin only during an i2c transfer, and leave the v cc pin floating the rest of the time (see figure 10 ). depending on the application?s rf data transfer flow, it might also be wise to add a third level of safety: once an rf session (several commands) is completed, blindly send a write-sector password command with a wrong password value: this will set the internal flag defining the status of the presented password (flag set as ?wrong password presented?). case 3: the m24lrxxe_r application is not powered this is the typical case where the application is packed in a box (at the end of the production line) and the data update is performed through rf. the only condition for a safe application design is that the sensitive data stored in the m24lrxxe_r memory are protected with rf passwords, so that a spurious rf command could not modify these data. table 4. m24lrxxe_r status according to command and v cc supply command processed by the m24lrxxe_r v cc pin status device status i2c command v cc supplied i2c busy state rf command v cc supplied or v cc = high impedance the m24lrxxe_r is fully dedicated to rf commands
revision history AN4125 14/15 doc id 023297 rev 1 3 revision history table 5. document revision history date revision changes 15-jun-2012 1 initial release.
AN4125 doc id 023297 rev 1 15/15 please read carefully: information in this document is provided solely in connection with st products. stmicroelectronics nv and its subsidiaries (?st ?) reserve the right to make changes, corrections, modifications or improvements, to this document, and the products and services described he rein at any time, without notice. all st products are sold pursuant to st?s terms and conditions of sale. purchasers are solely responsible for the choice, selection and use of the st products and services described herein, and st as sumes no liability whatsoever relating to the choice, selection or use of the st products and services described herein. no license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted under this document. i f any part of this document refers to any third party products or services it shall not be deemed a license grant by st for the use of such third party products or services, or any intellectual property contained therein or considered as a warranty covering the use in any manner whatsoev er of such third party products or services or any intellectual property contained therein. unless otherwise set forth in st?s terms and conditions of sale st disclaims any express or implied warranty with respect to the use and/or sale of st products including without limitation implied warranties of merchantability, fitness for a parti cular purpose (and their equivalents under the laws of any jurisdiction), or infringement of any patent, copyright or other intellectual property right. unless expressly approved in writing by two authorized st representatives, st products are not recommended, authorized or warranted for use in milita ry, air craft, space, life saving, or life sustaining applications, nor in products or systems where failure or malfunction may result in personal injury, death, or severe property or environmental damage. st products which are not specified as "automotive grade" may only be used in automotive applications at user?s own risk. resale of st products with provisions different from the statements and/or technical features set forth in this document shall immediately void any warranty granted by st for the st product or service described herein and shall not create or extend in any manner whatsoev er, any liability of st. st and the st logo are trademarks or registered trademarks of st in various countries. information in this document supersedes and replaces all information previously supplied. the st logo is a registered trademark of stmicroelectronics. all other names are the property of their respective owners. ? 2012 stmicroelectronics - all rights reserved stmicroelectronics group of companies australia - belgium - brazil - canada - china - czech republic - finland - france - germany - hong kong - india - israel - ital y - japan - malaysia - malta - morocco - philippines - singapore - spain - sweden - switzerland - united kingdom - united states of america www.st.com

▲Up To Search▲

Price & Availability of AN4125

	To Download AN4125 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .