So I took your code and tried it. Yes, I had to install the "Roger" core to get it to compile. It has been a very long time since I used this core and I have either forgotten, or perhaps I never did know where Serial2 goes to, so all I did initially was to redefine Serial2 as Serial so I could see the output.
Duly loaded into a Bluepill board, and it repeatedly printed the timer registers and "error". Now given there was no DHT11 attached, that is no big surprise. I don't have a DHT11, but not easily defeated, I programmed another Bluepill to act the part of a DHT11 (just sending bogus constant humidity and temperature values). For good measure I put an external 5.6K pullup resistor to 3.3V.
Now your code seems perfectly happy to say things are OK:
Code: Select all
15:15:57.280 -> TIMER2_BASE->CR1 =1;
15:15:57.280 -> TIMER2_BASE->CR2 =0;
15:15:57.280 -> TIMER2_BASE->SMCR =0;
15:15:57.280 -> TIMER2_BASE->DIER =0;
15:15:57.280 -> TIMER2_BASE->EGR = 0;
15:15:57.280 -> TIMER2_BASE->CCMR1 = 0;
15:15:57.280 -> TIMER2_BASE->CCMR2 = 0;
15:15:57.280 -> TIMER2_BASE->CCER = 0;
15:15:57.280 -> TIMER2_BASE->PSC = 71;
15:15:57.280 -> TIMER2_BASE->ARR = 65535;
15:15:57.280 -> TIMER2_BASE->DCR = 0;
15:15:57.280 ->
15:15:57.280 -> 1
15:15:57.467 -> OK
15:15:59.457 -> TIMER2_BASE->CR1 =1;
15:15:59.457 -> TIMER2_BASE->CR2 =0;
15:15:59.457 -> TIMER2_BASE->SMCR =0;
15:15:59.457 -> TIMER2_BASE->DIER =0;
15:15:59.457 -> TIMER2_BASE->EGR = 0;
15:15:59.457 -> TIMER2_BASE->CCMR1 = 0;
15:15:59.457 -> TIMER2_BASE->CCMR2 = 0;
15:15:59.457 -> TIMER2_BASE->CCER = 0;
15:15:59.457 -> TIMER2_BASE->PSC = 71;
15:15:59.457 -> TIMER2_BASE->ARR = 65535;
15:15:59.457 -> TIMER2_BASE->DCR = 0;
15:15:59.457 ->
15:15:59.503 -> 1
15:15:59.691 -> OK
...
That repeats for as long as I let it.
So, I then inserted code to print the DHT11_data array just before it says "OK":
Code: Select all
15:34:23.885 -> 82
15:34:23.885 -> 26
15:34:23.885 -> 27
15:34:23.885 -> 27
15:34:23.885 -> 27
15:34:23.885 -> 27
15:34:23.885 -> 27
15:34:23.885 -> 27
15:34:23.885 -> 71
15:34:23.885 -> 71
15:34:23.885 -> 71
15:34:23.885 -> 71
15:34:23.885 -> 71
15:34:23.885 -> 27
15:34:23.885 -> 71
15:34:23.885 -> 27
15:34:23.885 -> 27
15:34:23.885 -> 27
15:34:23.885 -> 27
15:34:23.885 -> 27
15:34:23.885 -> 27
15:34:23.885 -> 26
15:34:23.932 -> 26
15:34:23.932 -> 70
15:34:23.932 -> 71
15:34:23.932 -> 71
15:34:23.932 -> 71
15:34:23.932 -> 71
15:34:23.932 -> 27
15:34:23.932 -> 26
15:34:23.932 -> 70
15:34:23.932 -> 70
15:34:23.932 -> 71
15:34:23.932 -> 71
15:34:23.932 -> 71
15:34:23.932 -> 26
15:34:23.932 -> 70
15:34:23.932 -> 70
15:34:23.932 -> 70
15:34:23.932 -> 71
15:34:23.932 -> 71
15:34:23.932 -> 0
15:34:23.932 -> 0
15:34:23.932 -> 0
15:34:23.932 -> 0
15:34:23.932 -> 0
15:34:23.932 -> 0
15:34:23.932 -> 0
15:34:23.932 -> 0
15:34:23.932 -> 0
15:34:23.932 -> OK
It is also happy to continue doing that for as long as I like. The time values printed might vary +/- 1, but you would have absolutely no problem translating those into the bit values.
So, where is the problem? Well, here are some comments & suggestions:
DHT11_data and index1 should be declared as volatile because they are updated in one of the interrupt routines.
It is not a good idea to print things within interrupt routines.
You seem to have "gotten away" with those two, but more of a problem is the fact that you do not check the array index in the handler_channel_1() ISR. If the sensor misbehaves, or if you get some random noise pulses on the sensor line, you can blindly plough on and destroy whatever happens to be in RAM beyond the array. That is a very good way to cause the sort of problem you reported earlier, where adding some "unused" variables might magically mask the problem. At the very least, you should not touch the array if the index gets too large, but actually, you might as well stop the timer as soon as you have all the data.
I would also suggest that in the Response() ISR, you should stop the timer counter (turn off CEN flag in CR1) before changing all the other registers, and then start the counter as the last thing there. While you are about it, you could set timer counter to zero there too, then you could perhaps generate an interrupt if the response takes too long, if something grinds to a halt part-way through a transmission (ARR value of around 5000???).
Another possibility, and maybe you were going to do that anyway, would be to put the yet-to-be-written code that translates the time values to data bits into the ISR. That would reduce the RAM usage considerably. Remember you only have 20k and it can get used up very easily.
What is the library that you were going to use?