Change in simtrace2[master]: cardem: Use USART timeout for waiting time

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

laforge gerrit-no-reply at lists.osmocom.org
Mon Apr 5 12:25:41 UTC 2021


laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/simtrace2/+/23620 )

Change subject: cardem: Use USART timeout for waiting time
......................................................................


Patch Set 2:

(5 comments)

https://gerrit.osmocom.org/c/simtrace2/+/23620/2//COMMIT_MSG 
Commit Message:

https://gerrit.osmocom.org/c/simtrace2/+/23620/2//COMMIT_MSG@1 
PS2, Line 1: Parent:     d6005fcd (make sim switch board specific)
actaully, the clock signal is connected (TCLK1).  It's the I/O signal which is not connected to any TIO{A,B}1 so we cannot determine when exactly a bit starts or ends on the I/O line.


https://gerrit.osmocom.org/c/simtrace2/+/23620/2/firmware/apps/cardem/main.c 
File firmware/apps/cardem/main.c:

https://gerrit.osmocom.org/c/simtrace2/+/23620/2/firmware/apps/cardem/main.c@a168 
PS2, Line 168: #if 0
unrelated change.


https://gerrit.osmocom.org/c/simtrace2/+/23620/2/firmware/libcommon/include/simtrace_prot.h 
File firmware/libcommon/include/simtrace_prot.h:

https://gerrit.osmocom.org/c/simtrace2/+/23620/2/firmware/libcommon/include/simtrace_prot.h@236 
PS2, Line 236: 	uint3
waiting_time to wt rename should be one purely cosmetic patch (if at all)


https://gerrit.osmocom.org/c/simtrace2/+/23620/2/firmware/libcommon/source/card_emu.c 
File firmware/libcommon/source/card_emu.c:

https://gerrit.osmocom.org/c/simtrace2/+/23620/2/firmware/libcommon/source/card_emu.c@424 
PS2, Line 424: 		if (ISO_S_WAIT_POWER == new_state) {
the UART I/O related changes are independent of the USART timer changes.

To be honest, I don't see how those do anything at all.  The UART I/O lines are all routed to the peripheral function via the PIO_PER (peripheral enable register).  Unless you disable the peripheral via PIO_PDR, the changes to the GPIO output data via PIO_SODR / PIO_CODR done here  are no-ops as the alternate function always overrides any configured output levels.  How was this tested/validated?  Maybe there are some hardware bugs I'm unaware of?


https://gerrit.osmocom.org/c/simtrace2/+/23620/1/firmware/libcommon/source/mode_cardemu.c 
File firmware/libcommon/source/mode_cardemu.c:

https://gerrit.osmocom.org/c/simtrace2/+/23620/1/firmware/libcommon/source/mode_cardemu.c@217 
PS1, Line 217: ("%
> not sure we want to make this a non-fatal error. Clearly this should never happen...
Done



-- 
To view, visit https://gerrit.osmocom.org/c/simtrace2/+/23620
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: simtrace2
Gerrit-Branch: master
Gerrit-Change-Id: Ibcb2c8cace9137695adf5fb3de43566f7cfb93b5
Gerrit-Change-Number: 23620
Gerrit-PatchSet: 2
Gerrit-Owner: laforge <laforge at osmocom.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: tsaitgaist <kredon at sysmocom.de>
Gerrit-Comment-Date: Mon, 05 Apr 2021 12:25:41 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: laforge <laforge at osmocom.org>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20210405/b0623f5e/attachment.htm>


More information about the gerrit-log mailing list