Leon Lindenfelser
Forum Replies Created
-
AuthorPosts
-
November 18, 2016 at 8:56 am in reply to: What version of libmdot, mbed rtos, mbed should be used. #15533
Leon Lindenfelser
ModeratorHi Yogesh,
What versions of libmdot, mbed rtos and mbed are you using now? If you want to move forward but don’t want to move to mbed-os 5, what are you hoping to achieve by moving forward? Is there a feature, function or bug fix you are looking for?
Ideally, I’d recommend that you move to mbed-os 5. What problems are you concerned about with mbed-os 5? If you use the correct versions, it should be fine. If you move to mbed-os 5 and use our libmDot-dev-mbed5 there are some enhancements that may be worth while.
Here’s the libmDot-dev-mbed5 change log:
https://developer.mbed.org/teams/MultiTech/wiki/Dot-library-change-logHere’s the list of libmDot-dev-mbed5 versions. If you read the comments column you’ll see what versions of mbed-os to use with each libmDot-dev-mbed5 version. Avoid mbed-os 5.1.5 if you are using the I2C interface in your application.
https://developer.mbed.org/teams/MultiTech/code/libmDot-dev-mbed5/shortlogHave you used mbed-cli yet?
https://docs.mbed.com/docs/mbed-os-handbook/en/5.1/dev_tools/cli/
Once you get to using it, you may find it easier to work with.Kind regards,
LeonNovember 11, 2016 at 11:02 am in reply to: Accessing the Internal Temperature Sensor of the mDot MCU #15439ModeratorHi Szymon,
ADC_TEMP is the peripheral pin in the mDot platform for the temp sensor. It is defined in the file:
mbed-os\targets\target_stm\target_stm32f4\target_mts_mdot_f411re\PeripheralPins.cKind regards,
LeonModeratorHi Mark,
In regards to your second question about modifying the dot-box, it is easy to open and it has an mDot built in with the form factor seen at this link.
https://developer.mbed.org/platforms/MTS-mDot-F411
So you would have easy access to the available peripherals of the mDot. Keep in mind that you have to manage your added component with the on board sensors.Leon
ModeratorGood deal. We appreciate your input an involvement!
ModeratorAndrew,
This will provide better clarity about what I thought might possibly be the issue you are seeing.
See the entry on date August 30, 2016 at 1:36 pm.Leon
ModeratorAndrew,
Is the wake pin floating or pulled low? It should be pulled low with a rising edge used to wake the mDot.
Leon
ModeratorMicheal,
As Steve indicated above, the current AT command code does not contain a command or set of commands for reading i/o. However, you can modify the AT command code to add a command or commands to support reading i/o or sensors and transferring the data.
https://developer.mbed.org/teams/MultiTech/code/mDot_AT_firmware/Kind regards,
LeonModeratorLyn,
Please take a look at the following document…
http://multitech.com/documents/publications/manuals/s000645.pdf
On the bottom of page 49 is the beginning of a section for programming external targets. We designed the xDot DK board so it can be used to program external xDots. Connect from JP1 on the xDot DK to your target xDot. In your case, I’d suggest that you place a like 9 pin connector on your board. Once connected and powered, the xDot DK will program your target rather than the xDot that is on the xDot DK. Does this answer your question?Leon
ModeratorHi Lyn,
You can also use an ST Link or Segger J-Link programmer but that’s essentially what Andrew is saying. Same method for programming… put a header for the xDot programming interface on your board and attach a programmer to flash the xDot.
Leon
October 28, 2016 at 2:05 pm in reply to: Cannot build mDot app offline after export from mbed online compiler #15195ModeratorRui,
Is your off line source at the same versions as what you used for the on line build? Your on line build probably used rtos version 117 and mbed version 121 along with the 1.0.8-1 libmDot version.
Leon
ModeratorHi Michael,
If you are using the mDot library, use the setTxPower(const uint32_t& power); API call. If you are using our AT command firmware, use the AT+TXP command.
Kind regards,
LeonModeratorHi Andrew,
Please provide an app that we can run to duplicate this issue and let us know what version of mbed, mbed-rtos and libmDot you are using to build it. Also, are you building off line or on line?
LeonModeratorMy error… COM 9 is the AT command port. Looks like the issue is that your mdot is in serial data mode. You need to escape that mode to send AT commands. Press the reset button on the UDK board and immediately send it +++ upon reset. Timing is tight so it may take a few tries to get it out. You can send more than three +’s but it needs at least three.
ModeratorTo clarify, what I stated above is true for the MDK board.
http://www.multitech.com/brands/micro-mdot-devkit
For the UDK 2.0 board…
https://developer.mbed.org/teams/MultiTech/wiki/Using-MultiTech-UDK-for-mDot-Dev
you will issue commands via the 9 pin serial connector.ModeratorHi Minh,
It looks like you are trying to issue commands on the debug port. Are you using a MultiTech developer card? Assuming you are, there are two ports that should enumerate. For AT commands, use the one that displays in teraterm as “COMxx: XR21V1410 USB UART”.
Leon
ModeratorFantastic, thanks for choosing MultiTech!
ModeratorWhen you plug the MDK with mdot into a computer, it should enumerate two ports. I’m assuming you are already using one of the two for communication to the mdot. The one that connects to the XR21V1410 is the one you need to control RTS on. If you are using Windows, you should see it in the device manager.
ModeratorJavier,
Q: So, if I run the program without using the MDK and nothing attached to PA_0 will it wake from RTC?
A: As long as the wake pin is low(pulled down) when deepsleep/standby is entered.Q: Is it possible to wake from deep sleep when attached to the MDK?
A: Yes, but you need to attach to the virtual serial port with RTS active so RTS is driven low from the XR21V1410 chip.I like your code above where you read and output the state of the wake pin. I recommend you use that to make sure the wake pin is low before going into deep sleep… at least until you pass this hurdle.
Leon
ModeratorJavier,
It’s an errata on the processor with a simple work around. The errata for the processor states…
“The various wakeup sources are logically OR-ed in front of the rising-edge detector which generates the wakeup flag (WUF). The WUF needs to be cleared prior to Standby mode entry, otherwise the MCU wakes up immediately.
If one of the configured wakeup sources is kept high during the clearing of the WUF (by setting the CWUF bit), it may mask further wakeup events on the input of the edge detector. As a consequence, the MCU might not be able to wake up from Standby mode.”So if the processor is configured to wake from, both RTC and the wake pin, then deepsleep/standby is initiated while the wake pin is already high, wake functionality will not work correctly.
To avoid this, make sure the wake pin is low when you enter deepsleep/standby. Wake it by raising the wake pin… or the RTC timer.
FYI: On the MDK, the wake pin is the RTS signal coming from the XR21V1410 chip. If you attach to the serial port and are manipulating RTS, you will see that RTS is logically inverted by the XR21V1410 chip.
Leon
ModeratorJavier,
PA_0 needs to be 0 not 1. That is the problem.
Leon
ModeratorJavier,
There is an errata with the STM32F411. The wake pin needs to be low upon going into standby mode. If the wake pin is in the wrong state (high), when entering standby mode, it will not wake. This is an issue only if both RTC and interrupt are enabled as wake up sources.
See secion 2.1.5
http://www.st.com/content/ccc/resource/technical/document/errata_sheet/0a/98/58/84/86/b6/47/a2/DM00037591.pdf/files/DM00037591.pdf/jcr:content/translations/en.DM00037591.pdfLeon
ModeratorThe input voltage range is listed in the datasheet as 9-32VDC.
http://www.multitech.com/datasheets/86002170.pdfModeratorHi Andrew,
Since I cannot attach firmware in this forum, I have made it available on our FTP site at: https://webfiles.multitech.com/engineering/diagnostic-code/mDot/
Be sure to choose the mdot debug version that corresponds to the frequency band of your target mdot (915Mhz or 868Mhz). The frequency band is restored as part of this process.Below are the instructions you will follow to erase flash and reprogram the mdot. Please note that without the debug firmware you can erase the flash but you cannot reconfigure the DevEUI and the frequency band will remain in the erased state.
With the debug firmware you will need to connect a terminal to the debug pins at 115200 and hit enter while resetting the mdot to enter the bootloader.
Issue “erase” to clear the flash memory.
> erase
Reset the device. Then on the command port program the DevEUI from the label on the mdot.
> AT+DI=0011223344556677
> AT&WPAt this point, flash memory is restored and you can reload the application. You can find the mdot AT command firmware application at…
Kind regards,
LeonModeratorHi Andrew,
We have seen occasions where the flash memory becomes corrupted when the mdot is run with a power source below 2.7v.
To fix the flash corruption, you need to erase it and re-program the DevEUI found on the label using some debug firmware. Please open a support case at https://support.multitech.com/support so we can provide you with the debug firmware and additional instructions.
Kind regards,
LeonModeratorHere is the manual I am referring to. I also checked the schematic. Pin 7 is definitely PC9. Can you point me to the manual you are looking at?
http://www.multitech.com/manuals/s000612_2_0_7.pdfModeratorPage 22 is correct. Pin 7 routes to PC9 and pin 8 routes to PA12 of the STM32F411RE processor.
ModeratorHi Andy,
Flow control(CTS/RTS) is enabled by default but is not in affect during command mode, only when on line. The other defaults are as you listed.
When you receive the unit, you can issue AT&V to view the settings.
LeonModeratorHi Alejandro,
That’s a very high current reading. On the MTUDK2.0 board, you can measure the current draw at JP90. See ‘http://www.multitech.com/manuals/s000612_2_0_7.pdf’ page 52. Look for JP90 in area D3(A-E and 1-4 on edge of schematic). On page 44 of the same document it shows the MTUDK2.0 PCB. Between ‘Serial Disconnect Header’ and ‘J-Link Header’ is where JP90 is and R118 is the little part to the left of JP90. With R118 removed and a current meter connected from the 3.3v pin to the center pin, I measure about 28uA when in sleep mode. I am using the mdot LoRa sleep example on mbed. To simplify the code, I commented out the network join code and had it go straight to sleep after configuration. Have you tried more than one mdot?
Kind regards,
LeonModeratorAccording to the STM32F411 datasheet, reset needs to be held low for at least 300ns… yes, that is nano seconds.
ModeratorHi Lawrence,
The values you included in your first post appear reasonable. The lux value is two bytes not three. I’ll have to track down why the documentation indicates 3 bytes.
We configure the light sensor for 16 bits and a range up to 16000 or 0x3e80. I don’t know what would cause the ffff value. Can you tell me more about when or how the ffff occurs for you?
Kind regards,
Leon -
AuthorPosts