Servus allerseits Bestellt habe ich die MCUs von Farnell; und drauf steht STM32F100 VET6 Y http://de.farnell.com/stmicroelectronics/stm32f100vet6/mcu-32bit-cortex-m3-24mhz-lqfp/dp/2333150?ost=2333150 Ich gehe also davon aus, dass ich ein F100 HighDensity ValueLine Revision Y in Haenden halte; was auch von "ST-Link-Utility" bestaetigt wird. Und auch meine Analyse der Device Signature bestaetigt das Obige. Entsprechend dem Datenblatt, dem ReferenzManual und AN4013 hat diese MCU 13 Timer. Timer 1 bis und mit 7 kann ich ansprechen und nach Gusto konfigurieren. Nicht so aber die Timer 12 bis und mit 17. Diese kann ich nicht einmal im Register RCC_APB1ENR bzw. RCC_APB2ENR auf 1 setzen. Bleibt stur auf 0. Ich vermute, dass meine Vermutung, ich haette vermutlich ein "F100 HighDensity ValueLine" in Haenden, nicht ganz im Einklang mit der Realitaet ist. Nur: was ist es dann?
Ich vermute, dass deine vermutete Vermutung vermutlich falsch ist. uff Das ist bestimmt nur ein doofer Fehler, von dem, der dein Programm geschrieben hat. ;) Zeig doch mal Code. Kann ja viele Gründe haben. DAF (dümmster anzumehmender Fehler) wäre 16Bit-Zugriff auf die Register.
Servus Detlef Also der Kod funktioniert mit den Timern 1 bis 7. Wird also nicht daran liegen. Als ich dann bei Timer-12 auf die Nase fiel und anfing den Kod zu kürzen, landete ich schlussendlich bei diesen paar Schritten:
1 | volatile static bool eflag = false; |
2 | |
3 | RCC->APB1ENR |= RCC_APB1Periph_TIM5; |
4 | if ((RCC->APB1ENR & RCC_APB1Periph_TIM5) == 0 ) |
5 | eflag = true; |
6 | RCC->APB1ENR |= RCC_APB1Periph_TIM12; |
7 | if ((RCC->APB1ENR & RCC_APB1Periph_TIM12) == 0 ) |
8 | eflag = true; |
Bei TIM5 wird das Bit gesetzt, bei 12 nicht. RCC_APB1Periph_TIM12 wird übrigens korrekt mit 0x40 übersetzt.
> cd STM32Cube/Repository/STM32Cube_FW_F1_V1.0.0/Drivers/CMSIS/Device/ST/STM3 2F1xx/Include > grep RCC_APB1Periph_TIM12 * => Kein treffer > grep RCC_APB1ENR_TIM12 * stm32f100xe.h:#define RCC_APB1ENR_TIM12EN ((uint32_t)0x00000040) /*!< TIM12 Timer clock enable */ stm32f101xg.h:#define RCC_APB1ENR_TIM12EN ((uint32_t)0x00000040) /*!< TIM12 Timer clock enable */ stm32f103xg.h:#define RCC_APB1ENR_TIM12EN ((uint32_t)0x00000040) /*!< TIM12 Timer clock enable */ Du verwendest die falschen Defines!
Uwe, ich verwende nicht die Cube-Software. Weshalb ich auf meinem Rechner auch keine Datei mit dem Namen stm32f100xe.h habe. Aber auch dort würde das Define mit 0x40 ersetzt werden.
:) Nein. Er meinte du, hast RCC_APB1Periph_TIM12 statt RCC_APB1ENR_TIM12EN verwendet.
Mehmet Kendi schrieb: > Uwe, ich verwende nicht die Cube-Software. Weshalb ich auf meinem > Rechner auch keine Datei mit dem Namen stm32f100xe.h habe. Diese Datei ist auch nicht Teil der Cube Library, sondern der CMSIS. Wo käme denn sonst die Definition von "RCC" und "APB1ENR" her? Weil genau da müsste sich auch RCC_APB1ENR_TIM12EN etc. finden. Das von dir verwendete RCC_APB1Periph_TIM12 kommt aber sehr wohl aus der Cube/Standard Peripheral Library...
Ist mir schon klar. Aber beide haben den wert 0x40. Uwe hat aber insofern recht, dass in stm32f10x.h das Define STM32F10X_HD_VL aufgelöst wird und dort steht in der Tat RCC_APB1ENR_TIM12EN. Aendert aber insforn nichts an der Tatsache, dass auch daneben 0x40 steht. Und wenn ich den Kod dieses Define benutzend aendere, aendert sich am beanstandeten Verhalten nichts. Leider.
Als High density device sollte die DeviceID in 0xE0042000 0x428 sein. Stimmt die Devcie ID? Und passt die Flash Size in 0x1FFF F7E0?
Lese mal nach der Sequenz oben das RCC Register mit dem Debugger aus. Vielleicht ist TIM12 anders angebebunden als TIM5 und der Chip braucht einigen Zyklen aehnlich dem F446 Errata "Delay after an RCC peripheral clock enabling". Laesst sich das TIM12 Register Bit im Debugger setzen?
Uwe Bonnes schrieb: > Als High density device sollte die DeviceID in 0xE0042000 0x428 sein. Ich hoffe, dass wir nun der Sache etwas naeher kommen. Denn mit Bezug auf das ReferenzManual RM0041 Doc-ID 16188 Rev 4 ist die DeviceID-Adresse bei mir mit 0x1FFFF7E0 angegeben. Und dort steht der Wert 0x414. Also STM32F10x (High Density) Das ReferenzManual habe ich übrigens, nachdem ich mit Timer-12 an die Wand gefahren bin, um ganz sicher zu gehen nochmals von der ST-WebSeite runtergeladen. http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1031/LN775/PF216853?s_searchtype=partnumber -> Tab "Design Resources"
Uwe Bonnes schrieb: > Laesst sich das TIM12 Register Bit im Debugger setzen? Nein, nur die von mir erwaehnten Timer 1 - 7 lassen sich mit dem Debugger setzen. All die anderen bleiben stur auf 0.
Angehängte Dateien:
-
F100.PNG
44 KB
Datenblatt lesen ist wohl nicht Deine Staerke... Mehr als 7 (sieben) Timer sind in nem F100VE nicht drin.
Angehängte Dateien:
-
stm32f100xx_timer.jpg
88 KB
Nicht angemeldeter Gast schrieb: > Mehr als 7 (sieben) Timer sind in nem F100VE nicht drin. Mein Datenblatt (März/2015 Version 8) sagt da aber was anderes. Und dein Flash- und RAM-Größen stimmen ja mal gar nicht. :P Deine "Datenblatt" muß von 2008/2009 sein. ^^
:
Bearbeitet durch User
Sag mir wo die Timer sind, wo sind sie geblieben . . .
Falk Brunner schrieb: > Sag mir wo die Timer sind, wo sind sie geblieben . . . In der Tat summte ich beim Verfassen des Beitrags das Lied von Marlene. Sag mir wo die Timer sind Wo sind sie geblieben Sag mir wo die Timer sind Was ist gescheh'n ...
Angehängte Dateien:
-
STM32F100xC_xD_xE.gif
72 KB
Nicht angemeldeter Gast schrieb: > Datenblatt lesen ist wohl nicht Deine Staerke... > Mehr als 7 (sieben) Timer sind in nem F100VE nicht drin. Danke, dass Du Dir die Mühe gemacht und rechechiert hast. Ich kann aber nicht nachvollziehen, wieso Du, bevor Du Dein Ergebnis praesentierst, zuerst Dein Bedürfnis befriedigst, den Hilfesuchenden zu beleidigen. Leider sagt mein Datenblatt (das ich übrigens waehrend diesem mehrtaegigem Horrortrip zur Sicherheit 2x von der ST-Webseite runtergeladen habe), dass ich - je nachdem, wo ich nachsehe - zwiwchen 11 und 13 Timern haben müsste. Siehe Anhang, der von 11 Timern spricht.
Lade doch mal dein Projekt hoch, ich will das mal durch den Simulator oder einen F103 jagen.
Detlef, ich glaube, F100 ValueLine und F103 sind nicht dieselbe MCU-Familie. Aber einmal auch diese Familie anzuschauen finde ich eine gute Idee. Also, wenn man sich den STM32F103(VE) anschaut, dann steht im Datenblatt erste Seite: 11 Timer Datenblatt Device Overview: 8 Timer (korrigiert, stand vormals 6) AN4013 und das ReferenzManual: 14 Timer. Um sicherzugehen habe ich das Ganze mit dem EWARM getestet. Mit dem Simulator konnte in RCC alle 14 Timer aktivieren. Als ich dann ein Board mit eben diesem STM32F103VE anschloss und mit dem ST-Link dasselbe versuchte, konnte ich im Debugger nur 8 Timer aktivieren: Timer 1, 2, 3, 4, 5 , 6, 7 und 8 Um Zweifen auszuschliessen, habe ich den J-Link aus der Schublade goholt. Aber auch hier dasselbe Ergebnis mit 8 Timern.
:
Bearbeitet durch User
Mehmet Kendi schrieb: > Detlef, ich glaube, F100 ValueLine und F103 sind nicht dieselbe > MCU-Familie. Nun, das ist die F1xx-Familie. Das hex oder binary würden für eine Anlyse reichen, wenn dir die Source zu peinlich ist. Aber ich bettle nicht drum. Es wäre nur interresant, was man an dem Ding falsch machen kann. Ohne Zuarbeit keine Hilfe!
:
Bearbeitet durch User
Mehmet Kendi schrieb: > m sicherzugehen habe ich das Ganze mit dem EWARM getestet. > Mit dem Simulator konnte in RCC alle 14 Timer aktivieren. > Als ich dann ein Board mit eben diesem STM32F103VE anschloss und mit dem > ST-Link dasselbe versuchte, konnte ich im Debugger nur 8 Timer > aktivieren: > Timer 1, 2, 3, 4, 5 , 6, 7 und 8 Dann schick das Ganze an den FAE von ST. Und die Antwort bitte wieder hier einstellen.
Detlef Kunz schrieb: > Das hex oder binary würden für eine Anlyse reichen, wenn dir die Source > zu peinlich ist. Nein, meine Kods sind mir nicht peinlich. :) Nur bin ich dabei, die Software für ein "ich-erschlag-damit-die-meisten-meiner-Probleme-Board" zu entwickeln. Und da ist vieles drauf, was ich, um die Uebersichlichkeit zu bewahren, wegschneiden müsste. Werde versuchen es bis morgen hinzukriegen.
Fragen einfach fragen schrieb: > Dann schick das Ganze an den FAE von ST. Und die Antwort bitte wieder > hier einstellen. Natürlich werde ich dies machen, falls hier keine Lösung gefunden wird. Aber meist wird hier in diesem Forum eine Lösung gefunden. Weshalb ich mir den beschwerlichen Weg zu ST ersparen würde. Denn dort müsste ich, um die Etikette zu wahren, erst mal meine Frage im dortigen Forum stellen.
Mehmet Kendi schrieb: > Denn dort müsste ich, > um die Etikette zu wahren, erst mal meine Frage im dortigen Forum > stellen. Ja? Ich ruf dort einfach an, mache die Dringlichkeit deutlich und schiebe die Anfrage per Email an genau die Person nach. Das hat immer gut geklappt, nicht nur bei ST.
Ich habe jetzt eine Anfrage an den Support von ST eingereicht. Nach Murphys Gesetz wird jetzt hier in diesem Forum einer die banale Lösung praesentieren und so die Prophezeiung von Detlef Detlef Kunz schrieb: > DAF (dümmster anzumehmender Fehler) bewahrheiten. Okay, ich warte ...
Detlef, beiliegend das von Dir gewünschte zusammengestutze Projekt. Das Ganze ist auf einem RTOS aufgesetzt und die Software muss auf demselben Board sowohl einen F100'er, als auch einen F407'er bedienen können; weshalb nach diesem Kahlschlag vielleicht jetzt manches etwas seltsam wirken mag. In main() ruft die App.Init() auf, wo die Timer initialisiert werden. Wie gesagt: bis auf TIM12 keine Probleme. Hoffe Du findest den Wurm.
:
Bearbeitet durch User
Ok, habs compiliert. Und auf eine 103ZE übertragen. 12/13/14 gehen nicht. Hätt ich mir sparen können, ohne Programm, nur von Hand gesetzt, gehen die auch nicht. Liegt also nicht am Programm. Irgendwas übersehen wir, oder da ist was oberfaul.
Detlef Kunz schrieb: > Und auf eine 103ZE übertragen. > 12/13/14 gehen nicht. Das darf aber nicht wundern, denn bei ST steht: http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1031/LN1565/PF164495 ... Up to 11 timers ...
Wunder über Wunder schrieb: > Detlef Kunz schrieb: >> Und auf eine 103ZE übertragen. >> 12/13/14 gehen nicht. > > Das darf aber nicht wundern, denn bei ST steht: > http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1... > ... Up to 11 timers ... Ah, klar, der 103ZE hat nur 1..8. Aber der 100VE sollte 1...7 und 12...16 haben.
Hmm, was für ein 16BitWert steht an Adresse 0x1FFF F7E0
:
Bearbeitet durch User
Zumindestens beim F103xG lassen sich Timer 2-7 und 12-14 setzten: (gdb) x /x 0xE0042000 0xe0042000: 0x10006430 (gdb) x /x 0x1FFFF7E0 0x1ffff7e0: 0x00600400 (gdb) p /x *(int *) 0x4002101c $1 = 0x0 (gdb) p /x *(int *) 0x4002101c = 0x1ff $2 = 0x1ff (gdb) p /x *(int *) 0x4002101c $3 = 0x1ff
Irgendwie werde ich das Gehühl nicht los, dass hier unterschiedliche Chip Revisionen unterwegs sind. @Mehmet: Du schreibst im ersten Post, dass du die Revision 'Y' hast. Lt. Datenblatt von ST gibt es aber nur eine Revision 'A' für die High Density Typen und 'Z' & 'A' für die low/medium Density Versionen. Kannst du das DBGMCU_IDCODE ( 0xE0042000 ) Register auslesen, um zu sehen was dort drin steht. Dort steht die Rev_ID (Revsion) drin. http://www.st.com/st-web-ui/static/active/en/resource/technical/document/reference_manual/CD00246267.pdf Seite 647 Was noch zu der Theroie mit den unterschiedlichen Silzium Versionen passen würde ist, dass hier Beitrag "Re: STM32F100VE: wo sind die Timer, wo sind sie nur?" ein Ausschnitt aus einem alten DB verhanden ist, welches nur 8 Timer ausweist, aber in den neueren DB mehr Timer vorhanden sind. Vielleicht hat ST mit einer neuen Chip Vserion noch zusätzliche Timer spendiert bzw. freigeschaltet. Kannst du mal schauen wann dein Bautein hergestellt wurde. Die Herstellungswoche + Jahr sollte auf dem Gehäuse drauf sein. Nicht dass es ein Uralttyp ist. http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/CD00212417.pdf Seite 95 Ich frag morgen mal bei unseren Distri an, ob es zu dem Typ PCNs gibt. Gruß Jörn
Jörn Kaipf schrieb: > Du schreibst im ersten Post, dass du die Revision 'Y' hast. > Lt. Datenblatt von ST gibt es aber nur eine Revision 'A' für die High > Density Typen und 'Z' & 'A' für die low/medium Density Versionen. Sorry für die verspaetete Antowrt. War den ganzen Tag bei Kunden. Es ist richtig, das ST meist mit 'A' beginnt und mit 'Z' abschliesst; um anzudeuten, dass da nichts mehr Neues kommen wird. In diesem speziellen Fall hat aber ST wegen ein paar eklatanten Fehlern eine neue Revision nachschieben müssen. Und die erhielt dann eben die Bezeichnung 'Y'. Edit: Gelesen hatte ich die Info auf irgendeiner Support-Seite. Kann sie aber nicht mehr finden.
:
Bearbeitet durch User
Angehängte Dateien:
-
stm32.gif
58 KB
Jörn Kaipf schrieb: > Kannst du mal schauen wann dein Bautein hergestellt wurde. Die > Herstellungswoche + Jahr sollte auf dem Gehäuse drauf sein. Nicht dass > es ein Uralttyp ist. Siehe Beilage
Habe die Support-Seite gefunden. Leider beziehen sie sich dort auf "STM32F10xxx Medium-density devices"; hatte gemeint, es ginge um High-Density. Kann also sein, dass "Y" nicht wie von mir gemeint der letzte Schöpfungsakt von ST ist. http://supp.iar.com/Support/?Note=50011
Halo Mehmet, was hat der ST-support zu den fehlenden Timern gemeint? Gruß Helmut
Leider noch keine Antwort erhalten. Vermutlich dort ebenfalls verdutzte Gesichter und "ja wo sind sie nur?" Ausrufe. Werde die Antwort natürlich hier reinstellen, sobald sie eintrifft.
Scheint, als haette ich ein ganz glückliches Haendchen gehabt, als ich bei Farnell diese Dinger bestellte. Denn als ich per USART Status-Meldungen ausgeben wollte, erhielt ich unleserliche Zeichen praesentiert. Nach viel Kopfkratzen und noch mehr Einzelschritten mit dem Debugger stellte ich fest, dass ich PREDIV1 in RCC_CFGR2 nicht setzen konnte. Und ja, ich weiss, dass dafür PLL nicht aktiv sein darf. Umschifft habe ich diese Klippe, indem ich PLLMULL von x6 auf x3 einstellte. (Quarz = 8MHz) Okay, ich gehe mal davon aus, dass ich von Farnell Ramsch erhalten habe. Kann passieren. Da ich nur 10 davon bezogen habe, werde ich das Ganze nicht unter der Rubrik "Tragödie" abbuchen müssen. Haette aber auch 100 sein können. Und da waere meine Reaktion nicht so nonchalant ausgefallen. Wobei ein Knurren und Bellen vermutlich mir auch nicht mehr eingebracht haette. Mich würde es nun brennend interessieren, wie ich solche Missgriffe in Zukunft vermeiden kann. Denn ich verbrauche keine Mengen, die es mir erlauben würden, für den Einkauf direkt mit ST in Kontakt zu treten.
Mehmet Kendi schrieb: > Mich würde es nun brennend interessieren, wie ich solche Missgriffe in > Zukunft vermeiden kann. Denn ich verbrauche keine Mengen, die es mir > erlauben würden, für den Einkauf direkt mit ST in Kontakt zu treten. Deinen Beitrag finde ich sehr interessant! Wenn Du keine großen Stückzahlen brauchst, nimm doch einfach Alles zwei Nummern größer: F407. Gut, der kostet mehr aber macht all die feinen Sachen, die man erwartet. Die Typen sind (glaube ich) nahezu pinkompatibel. Deutlich schneller und mit mehr RAM liegst Du bei (fast) allen Anwendungen auf der sicheren Seite. Den besten Preis hatte ich immer bei Future Electronics bekommen. Aktuell kosten sie 7,04 Euro ab zwei Stück. Vor einem Jahr waren es nur 4,62 :-(
Das Board ist sowohl für F100 als auch F407 konzipiert. Und je nach Aufgabenstellung, Anzahl und Kosten wollte ich zwischen diesen beiden waehlen. Der Missgriff an und für sich ist keine Katastrophe. Bis anhin konnte ich alle Klippen umschiffen. Nur eben viel Zeit verloren, die eh schon knapp ist. Es ist nur so, dass ich jetzt sehr verunsichert bin. Selbst wenn ich einen F407'er einsetze: woher weiss ich, dass ich nicht wieder Ramsch erhalte? Bei der glücklichen Hand die ich anscheinend habe :)
Mehmet Kendi schrieb: > Bei der glücklichen Hand die ich anscheinend habe :) Jede Rattenfamilie hat einen Vorkoster. Das ist nun Deine Aufgabe - da mußt Du durch ;-)
Ich glaube, ST stellt für die Türkei separate MCUs her. Kann ich durchaus nachvollziehen. Denn waehrend die türkische Regierung uns versichert, dass wir morgen, spaetestens übermorgen einer der ersten 10 Industriestaaten sein werden, sieht die Sache, wenn man es vom Ausland her betrachtet doch eher so aus, als würde sich die Türkei Richtung Mittelalter bewegen. Zwar langsam, aber beharrlich. Und dort war Zeit doch eher nicht so wichtig. Um auf die STM32 zurückzukommen: Wenn ich RS Components mir anschaue: Lieferung in die Türkei erfolgt mit 7 Timern: http://tr.rsdelivers.com/product/stmicroelectronics/stm32f100vet6/stm32f100vet6-32-bit-arm-cortex-m3-microcontroller-24mhz-512-kb-flash-32-kb-ram-%C4%B12c-100-pin-lqfp/8103491.aspx?query=STM32F100VET6 Bestelle ich sie aber in England, habe ich die Wahl zwischen 11 und 16 Timern: http://uk.rs-online.com/web/c/semiconductors/processors-microcontrollers/microcontrollers/?searchTerm=STM32F100VET6&h=s&sra=oss&redirect-relevancy-data=636F3D3226696E3D4931384E4B6E6F776E41734D504E266C753D656E266D6D3D6D61746368616C6C7061727469616C26706D3D5E5B5C707B4C7D5C707B4E647D2D2C2F255C2E5D2B2426706F3D313326736E3D592673743D4D414E5F504152545F4E554D4245522677633D424F5448267573743D53544D3332463130305645543626 PS: die Webseite von RS Components ist z.Zt. sehr lahm.
Eventuell auch mal bei Farnell nachfragen ob die nachvollziehen können wo die Teile denn herkommen... kann ja sein das das umgelabelte "Fakes" sind? Kann heutzutage vorkommen, dass von Fälschern eine kleinere CPU als eine größere umgelabelt / modifiziert wird (ID ändern beim STM32? k.a. ob das geht)... ist der Flashspeicher voll nutzbar (testdaten reinschreiben und wieder auslesen)?
Mehmet Kendi schrieb: > Ich glaube, ST stellt für die Türkei separate MCUs her. Heh lol das könnte natürlich auch sein... Wäre aber ziemlich sinnfrei ;-)
Es gibt auch Positives aus der Düsternis zu berichten. Ich debugge sehr gerne im SRAM. Aber mit 32kB im Rucksack sind natürlich keine ausgiebigen Wanderungen möglich. Als es dann soweit war und ich schon auf Flash umschalten wollte ... In irgendeinem Referenzmanual (weiss jetzt nicht mehr, welches es war) hatte ich irgendwann mal in der Rubrik "Revision History" gelesen, dass man das Register für die Sram-Grösse entfernt habe. Kann mich jetzt nicht entsinnen, ob damit nun gemeint war, dass nur der Hinweis, oder das Register selbst entfern wurde. Mit etwas Nachforschung entpuppte sich die Adresse dieses Registers als "Flash Size Register" + 2 Bytes. Und dort steht bei diesem meinem Ramsch-MCU nicht 32, sonder stolz die Zahl 64. Eine einfache Ram-Test Routine, bei der jedes Byte von 0 auf 255 hochgezaehlt und kontrolliert wird, zeigte bei diesem Extra-Ram keine Fehler. (Ob beim Test Nachbarzellen betroffen wurden, habe ich nicht kontrolliert.) Vermutlich wird nur ein F1xx Chip mit allem PiPaPo hergestellt und dann je nach Testergebnis etikettiert.
Mehmet Kendi schrieb: > zeigte bei diesem Extra-Ram keine > Fehler. (Ob beim Test Nachbarzellen betroffen wurden, habe ich nicht > kontrolliert.) Solltest du aber nochmal auf Spiegelung testen, denn es kann ja sein, das sich die 32k einfach 2 mal wiederholen. Also mal <RAMPAGE>0x0000 auf irgendwas setzen und schauen, ob es bei <RAMPAGE>0x8000 auch schon steht.
Matthias Sch. schrieb: > Solltest du aber nochmal auf Spiegelung testen Habe ich natürlich gemacht; nur nicht daran gedacht, dies auch zu erwaehnen.
In regelmaessigen Abstaenden von ca. 4 Wochen kriege ich von ST eine
Benachrichtigung:
TECH005742 - ST - My request is updated - NEW - Timers higher
than TIM7 are not accessible
Wenn ich dann auf den Link klicke ("Please click the link below view the
details of this Incident"), bekomme ich mein Support-Ticket
praesentiert. Und das war's.
Da ich zum ersten Mal bei ST ein Support-Ticket erstellt habe, weiss ich
ehrlich gesagt nicht, was da vorgeht.
Die einzige Idee die mir in den Sinn kam: wenn ich 6 Monate lang diesen
mir zugesandten Link anklicke, erkennt ST, dass meine Anfrage ernst
gemeint war und ich auf eine Antwort insistiere; worauf das Ticket zum
Support weitergeleitet wird. :)
Jemand 'ne bessere Idee?
Habe eine "Antwort" von ST erhalten: Dear Customer, we have had an issue in our support service and some requests have been pending without support for a very long time. Your request is one of them and we are sorry about it. We suppose that your request is not valid anymore and we have terminated it (resolve status). Nevertheless, if your request is still relevant, you can refuse the resolution and we will process it. Sorry for the inconvenience. Best Regards, The microcontroller support team
Mehmet K. schrieb: > We suppose that your request is not > valid anymore and we have terminated it (resolve status). Klingt für mich so, als hätten sie die Timer repariert? Probiers doch mal aus :-P Aber sich die Antwort so einfach zu machen, finde ich nicht nett. Sieht also so aus, als müsstest du nochmal ein Ticket absetzen oder den Status auf 'unresolved' zurücksetzen, wenn das geht. Ganz klar sollte ein STM32F100VET6 ein highdensity Device sein und damit Timer 12-17 enthalten. Die Lücke ab Timer 8 - Timer 11 scheint allerdings Absicht zu sein, Timer 8 ist ein 'Advanced Timer' der F103 Serie und nicht im F100xE vorhanden.
Ich geb's auf. Hatte deren letzte Antwort mit "reject" beantwortet, worauf ich eine lange, aber inhaltslose Antwort erhalten habe. In meinem Ticket hatte ich alle relevanten Eckdaten festgehalten; aber jemand, der deren Antwort liest, kaeme auf die Idee, ich haette "Timer gehen nicht, warum nicht?" gefragt. Dear Customer, the datasheets are all correct. There are 13 timers in the RM0041Doc-ID 16188 Rev 4 and AN4013 because the 1xSysTick and 2xwatchdog timers are not included. Check the product number of your MCU, if there is a STM32F100VCT6Bxxx then the DocID15081 Rev 8 datasheet is the right one for your product. If there is not a "B" in your product number the right datasheet is DocID14611 Rev 10 for your product (http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/CD00191185.pdf). Compare the page 102 of the DocID15081 Rev 8 with the page 129 of the DocID14611 Rev 10. The first versions of STM32F100 purchased are the STM32F103 actually. In addition to this you may check if there is a letter "Z" or "A" in the end of the second line of the product number. "Z" stands for F103, "A" stands for F100. Best Regards, The microcontroller support team
Hmm, vielleicht antwortest du einfach leicht pampig in der Art "Vielen Dank, das Sie für mich das Datenblatt zitiert haben, ohne meine Anfrage vollständig gelesen zu haben. Ich habe hier einen xxxx mit Aufschrift yyyy und dort fehlen die Timer 12-17." Dann kannst du das Thema für dich immernoch abschließen.
Mehmet K. schrieb: > The first versions of STM32F100 purchased are the > STM32F103 actually. Mooment... das heisst doch, F100 steht drauf, aber F103 ist drin? Und die F103 habe diese Timer ja nicht.
A. K. schrieb: > Mooment... das heisst doch, F100 steht drauf, aber F103 ist drin? Und > die F103 habe diese Timer ja nicht. Dieser Hinweis ist mir auch aufgefallen. Aber dass Farnell solche alten Ladenhüter verkauft? Okay, kann sein. Aber was auch immer: wenn es für diesen speziellen Fall kein Datasheet existiert, oder kein Errata ... also dann gehe ich davon aus, dass - was auch immer im Hintergrund bei ST abfelaufen sein mag - ich anspruch auf die versprochenen Timer habe. Aber wie gesagt, habe ich das Thema für mich abgeschlossen. Hat mich zwar einiges an Zeit gekostet, aber schlussendlich konnte ich das Projekt erfolgreich abschliessen. Notiert habe ich mir: - keine STM32F100 mehr benutzten - keine grösseren Mengen bei Farnell bestellen, ohne sie vorher getestet zu haben.
Hi Mehmet, interessanter Fred. Tatsächlich wurde Dein Problem schließlich erklärt, allerdings wäre ich an Deiner Stelle unzufrieden. Wer zahlt den Aufwand und die Projektverzögerung? Ich habe in den letzten zehn Jahren persönlich mehrfach viel Aufwand in den Sand gesetzt, weil Silizium sich nicht ans Datenblatt gehalten hat. Übelste Beispiele: AT91RM9200, AVR32AP7000, TMS320F2812. Jedes Projekt hat sich dadurch ausgezeichnet, dass frühe Siliziumrevisionen von brandneuen Produkten zum Einsatz kamen. Und ich nach einigen Boardrevisionen meine ganz persönlichen Einträge im Errata-Sheet hatte. :( Meine jetzige Strategie: Wenn möglich neue Bausteine vermeiden, bis der Bedarf wirklich zwingend wird. Z.B. den STM32F7 schaue ich im Moment recht interessiert an, aber ich warte noch. Ansonsten zusätzliches Designrisiko einplanen und "täglich" nach den Erratas und Datenblättern und Appnotes schauen. Da ist bei ST viel Dynamik drin. Hätte aber bei Dir in diesem Fall wohl auch nix gebracht. Ein Alptraum wäre gewesen, wenn dies in der Produktion passiert wäre. Dabei baut ST doch eigentlich ganz brauchbare MCUs. Wenn ich für meine Kunden auch Fertigungssteuerung mache, kläre ich im Vorfeld welche Siliziumrevisionen zulässig sind. Diese werden dem Einkauf vorgegeben. Speziell bei Farnell hatte ich Anfang des Jahres das Problem, dass man mir bei der KSZ8863RLL nicht im Vorfeld sagen konnte, was im Lager liegt. Es kann sich auch um Mischbestände handeln! Oder es wird teils aus Belgien und teils aus England geliefert. Wenn so ein Lieferant dann trotzdem den Zuschlag bekommt, muss vor der Bestellung geklärt sein, was passiert, falls die Ware nicht passt. Und Farnell ist noch Gold, weil man im Zweifelsfall schnell anrufen kann. Wenn's die Projektlaufzeit hergibt, würde ich in so einem Fall lieber wo anders bestellen. Nochmal Danke, dass Du drangeblieben bist und anderen damit den Ärger ersparst. Grüße, marcus
Mehmet K. schrieb: > Servus allerseits > > Bestellt habe ich die MCUs von Farnell; und drauf steht > STM32F100 > VET6 Y > http://de.farnell.com/stmicroelectronics/stm32f100vet6/mcu-32bit-cortex-m3-24mhz-lqfp/dp/2333150?ost=2333150 > > Ich gehe also davon aus, dass ich ein F100 HighDensity ValueLine > Revision Y in Haenden halte; was auch von "ST-Link-Utility" bestaetigt > wird. Und auch meine Analyse der Device Signature bestaetigt das Obige. > > Entsprechend dem Datenblatt, dem ReferenzManual und AN4013 hat diese MCU > 13 Timer. > Timer 1 bis und mit 7 kann ich ansprechen und nach Gusto konfigurieren. > Nicht so aber die Timer 12 bis und mit 17. > Diese kann ich nicht einmal im Register RCC_APB1ENR bzw. RCC_APB2ENR auf > 1 setzen. Bleibt stur auf 0. > > Ich vermute, dass meine Vermutung, ich haette vermutlich ein "F100 > HighDensity ValueLine" in Haenden, nicht ganz im Einklang mit der > Realitaet ist. > Nur: was ist es dann? Noch ein Nachtrag: im obigen Datenblatt steht u.a.: 8 Revision History 09-Oct-2008 1 Initial Release 01-Sep-2010 3 Major Revision of whole document. Added LQFP144 package and additional peripherals (SPI3, UART4, UART, TIM5, 12, 14, 13, FSMC) Das hätte man also etwas AHNEN können - vorausgesetzt man prüft das Produktionsdatum bei jedem Materialeingang gegen das aktuelle Datenblatt. Kann es sein, dass auf Deinem Chip Datecode 822 steht? Wohlgemerkt ist das erstmal nur die Document revsion history - die Device Identification im Errata Sheet kennt Deine Y-Revision überhaupt nicht. Nun könntest Du an Farnell rantreten und fragen, wie es sein konnte, dass Du Anfang 2015 eine Y-Revision bekommst, die offensichtlich weder im Errata geleistet ist, noch den Spezifikationen im aktuellen Datenblatt entspricht. Eine Revision, die nach den vorliegenden Unterlagen nicht im Handel verfügbar war. Antwort ist wahrscheinlich wieder: "wir können den Lagerbestand nicht nachvollziehen" Du könntest um Austausch gegen A-Typen bitten.
Der Date-Code ist 322; also 2013 / 22. Woche Siehe: Beitrag "Re: STM32F100VE: wo sind die Timer, wo sind sie nur?" Marcus H. schrieb: > Nun könntest Du an Farnell rantreten ... um Austausch gegen A-Typen bitten. Ich lebe in Istanbul. Die dabei für mich entstehenden Versandkosten würden ein Mehrfaches des Warenwertes ausmachen. Und die A Typen; waeren die dann nich noch ein aelterer Jahrgang? Soweit ich es mitbekommen habe, nummeriert ST wie folgt: A, Z, Y, 1, 2, X Aber keine Ahnung, welche Logik dahintersteckt.
Mehmet K. schrieb: ... > Soweit ich es mitbekommen habe, nummeriert ST wie folgt: A, Z, Y, 1, 2, > X > Aber keine Ahnung, welche Logik dahintersteckt. Ja, ich habe mich auch gewundert, aber im Errata wird nur RevA gelistet. Wie auch immer, der Chip ist ein seltsames Pflänzchen. >Ich lebe in Istanbul. Das hatte ich irgendwie rausgehört, aber die Versandkosten bei Ersatz wären wohl das Problem des Lieferanten. Außer Du hast die erste Lieferung nicht nach Istanbul bekommen.
Marcus H. schrieb: > Das hatte ich irgendwie rausgehört Also Türken mit einem feinen Gehör merken zwar, dass was nicht stimmt. Aber noch kein Deutscher hat jemals stirnrunzelnd "moment mal..." gesagt. Du waerst also der erste :)
Hab ich natürlich "rausgelesen", guckst Du hier: Mehmet K. schrieb: > Ich glaube, ST stellt für die Türkei separate MCUs her. > Kann ich durchaus nachvollziehen. Denn waehrend die türkische > Regierung... Mein Gedanke war - wohnt in Istanbul und könnte einen Kurs "Deutsch für Forenteilnehmer" halten. break Weißt Du, aus welchem Lager Farnell nach Istanbul liefert? Wenn das nicht Belgien/England ist, lagen da vielleicht ein paar Ladenhüter.
Marcus H. schrieb: > Weißt Du, aus welchem Lager Farnell nach Istanbul liefert? Nach Aussage des türk. Vertreters von Farnell: England.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.